I have only been a professional software developer for a few years, but I feel like I have already acquired bad habits.

One of the hardest for me to break is the desire to create software in a cloistered environment where the requirements are stable and the best technical approach always wins over other constraints like schedule and cost.

Thankfully Highgroove’s iterative software development process forces me to flee from these broken methods of building applications.

Read on for more of my thoughts.

I have a formal degree in computer science, and I am glad I have it. However, all the assignments I completed in school had requirements that were set in stone. These requirements would be published, often on physical paper, and given out well in advance of the due date. This works well when attempting to be fair to all students, but customers in the real world rarely have requirements as stable as a classroom assignment.

The first company I worked for out of college claimed to do iterative development, but the process really felt like waterfall with a few small modifications. The solution to customers changing their requirements was to try to nail down those requirements sooner. Code was delivered in big releases every 6-9 months.

These experiences started to shape my instincts: sometimes I feel that uncertain or unclear requirements are a problem that must be solved before development can start in earnest.

That is so foolish. I am learning that developing interesting software often means it is impossible to know the “right answer” up front … and that is OK.

The answer to uncertainty in software is not to view it as a problem, but to embrace it.

How am I learning to do that .. practically?

Bias towards action: if the “right answer” to a problem seems unclear, bias towards implementing some solution (even if you know it’s not the best). Get it out there for the client (or even the client’s customers!) to use as soon as possible. The best solution will come by iterating on the non-ideal solutions you unabashedly tried at first.

Test-driven development: Coming up with solutions quickly is good, but not at the expense of bad code quality. The biggest wins of TDD are not code correctness (though that’s a nice byproduct), but the design feedback it gives. If the tests are hard to write, you are probably writing smelly code.

SOLID design principles: Learning about–and attempting to follow– the principles of the SOLID mnemonic have lead to improvements in the code I write. SOLID code is better able to handle the changes that will inevitably come when doing iterative development. For Rubyists specifically, I highly recommend Gregory Brown’s article and Jim Weirich’s talk.

In short, bad software development habits are easy to pick up, especially in formal education and in companies that have not truly adopted an agile/iterative approach. What bad habits have you broken–or are still breaking–when developing software?