You may have heard about test-driven development, or TDD. The idea is that you write all your tests, run them, watch them fail, and then write code that makes all the tests pass. There are many advantages to this approach. I have done projects with and without TDD, and the projects that used TDD came together more quickly and were more reliable. Yet myself and my teams still did not use TDD consitently. Why? Because it is a drag. Everyone knows that it is a better way to build a system, yet as you slog through the test writing, it is hard to convince yourself of that.

Along comes behavior-driven development, or BDD. Now instead of writing tests that fail (which is really pretty negative and depressing) you describe the desired behavior of your objects, and mark the implementation as pending. Since you probably have to document your objects anyway , it does not feel like a waste of time. And writing BDD tests is just more fun than traditional unit tests.

Some of the critics of BDD say it is just TDD with different terminologies and syntaxes. That’s more or less true. But anything that “tricks” developers into doing the right thing is worth paying attention to. Furthemore, you are likely to get better tests with more coverage, because the BDD frameworks make you want to write tests for everything.

Want to try out BDD? There are implementations for every major language. If you are using Ruby, check out the awesome RSpec framework. For other languages, see this page.

If you have tried TDD before and given up on it, give BDD a try. You will stick with it this time!

I used to think HTML and CSS were fine languages. Then I met Haml and Sass, and now I see the light. But first, a little perspective is in order.

Here is the assembly code and then the C code for a simple assignment and calculation:

MOVF id3, R2
MULF #60.0, R2
MOVF id2, R1
ADDF R2, R1
MOVF R1, id1

position = initial + rate ∗ 60

Compared to assembly language, C is operating at a much higher level, with benefits too obvious to enumerate here. But don’t forget that assembly language was a huge step up from hand-rolling machine code. And also recall that C++ took C to a new level of abstraction of by adding classes and templates. A language is “high-level” only in comparison to its brethren. Read More

The modern, SQL-driven relational databases arrived in the 80’s, before the Web had taken off. When developers started to build web-based applications, these databases were a natural choice for storing persistent data. Object-oriented databases (OODBs) were available, but they were not widely accepted due to performance and scalability issues. Here is the crucial point: relational databases were not chosen because they were a great fit for Web apps, they were chosen because that was the only realistic option available at the time.

With the arrival of Java and other object-oriented languages, the shortcomings of relational databases became more obvious. Developers now had to map their classes to tables in the database. Object-relational mappers like Hibernate made this process less painful, but it remained an awkward solution compared to using a real OODB. Read More

After a short hiatus from the series, I am proud to say we are back with another new business model. This week we are going to take a look at the data mining business model. Using this model means that revenue is generated as a result of data mining through the usage of a product. Nearly every business can use data mining as a way to increase revenue, but there is a growing trend to use data mining as a principle revenue stream. However, this approach does not come without its pitfalls.

Read More

Why bother spending the time and effort to create a clean, compelling resume? Is it really all worth it? After all, my code and projects speak for themselves. Right. Right? Besides, who else can write an orange peeling script in Bash that directly translates to assembly for deployment to my mechanical “peel a wizard” device.

Read More

It really is not a very difficult thing to master the art of salary negotiations. I spoke about some of the myths of software development salaries that were told to me when I applied for positions. Now, I will take a look at negotiating your salary during the employment process. The biggest mistake any applicant makes is filling in the area labeled “expected salary.” This is a question with no good answer, so it is best just to avoid answering. If you ask for too little the company will pay you that salary, but if you ask for too much they may pass over your resume all together.

Read More

Graduating from college can be a stressful time for any software developer. If your experience is anything like mine, you are told different theories from every person when it comes to salaries to expect from your first job. Well, let me tell you that these theories are rarely accurate. It all breaks down to the company and position that you end up being offered. Once you know this, the art of negotiation comes into play and if you do not know what you’re doing it ends up being very disappointing. Hopefully after reading this you will be better prepared to duke it out on your next offer.

Read More

For the series this week, we are going to take a look at a version business model. The main principle behind this model is providing different versions of the same software. The idea of creating multiple products out of a single application has been the most popularly adopted model for over a decade. Now, just like any business model there are some serious pitfalls and benefits of this approach. Luckily with many real world examples we can create a very accurate idea of this model.

Read More

I just wanted to apologize for not having a fresh post today. This is the first time I have missed a deadline and I hope it’s the last. Tomorrow will be the usual “Model Thursday” series and I will also try to get to another post to make up for today. Please consider contributing so this does not happen again. I have ideas for days just not enough time to write them all.