Bits of Art software matters

I have uploaded a small set of pictures from my recent trip to Flickr. Feel free to check it out!

I recently gave a short talk at the last Microsoft Health and Life Sciences 2009 developer conference in New York. The main theme was architecting health solutions in the cloud and challenges that come with it. You can watch the talk here.

There is a heated argument going on between Uncle Bob (Robert Martin) and Joel Spolsky (joined by Jeff Atwood). To recap some of the arguments, in a stackoverflow podcast Joel and Jeff undermined the value of using SOLID principles and things like TDD. Uncle Bob wrote a pretty strong blog post in response to the podcast. Although quite entertaining to read, something struck me really hard while I was going through the comments that are left on Uncle Bob’s blog. The comments on both sides were turning the discussion into a flame war on how to write good quality code. Using TDD or SOLID principles or not? Is testing needed or is it a waste of time?

It’s sort of interesting to see a slew of people with engineering or computer science backgrounds fighting religiously over one methodology over the other. One thing that stood out was how no one ever took a second to think what they were so frivolously defending. On one side there is a successful small business owner, ex-Microsofter, a geek world publicity on the other side there’s Uncle Bob who co-wrote the agile manifesto.

It is somehow assumed that people who are good at one thing should be naturally good at everything else. Following this assumption religiously can get anyone to narrow their horizon to the point where it might not be possible to realize that they are looking at the world through a needle hole. While it’s perfectly reasonable to get advice from Joel on how to start a small business, everything else he says should be taken with a grain of salt. After all, the blog and BOS Forum is there to create traffic and increase visibility of the FogCreek web site. Uncle Bob on the other hand is still a day to day developer, and in one of his blog posts he mentions the fact that he lets the experts do their job (he refers to them as business types doing their business thing) so he can concentrate on what he knows best; to write good OO code.

While SOLID principles are something that I personally love and try to follow every day, no one argues that those are the only principles that lead to perfect, clean implementations.

Developers using methodologies TDD, DDD, BDD UNIX or Windows platforms, functional or oo languages have only one thing in common that they have to do to write good code; THINK. Regardless of what three letter acronym you religiously follow, if you don’t think about what you’re doing you are destined to fail, through your chosen methodology’s fast route.

So what should you think about when writing good code? My list is pretty simple:

1. Do you clearly understand what you’re trying to achieve? Make sure you understand the problem you’re trying to solve by asking questions, reading that business requirement for a second time or just Google the problem domain!
2. Break it down. There’s a reason your college professor kept telling you this. Break down your problem into pieces that you can actually solve with 10-15 line methods each.
3. Verify the solution to each before moving to the next piece, mock if necessary: If the multi-step process requires interaction between the steps, don’t be afraid to mock it! You can check out Moq, RhinoMocks or TypeMock
4. Make sure that future enhancements won’t involve modification of existing code. (Check out the open/close principle article on wikipedia for more information on this)
5. Test for boundary conditions and see where your reasoning fails.
6. Repeat 1-5, cleanse and ship.

Following a simple sanity check like the one above, will save you lots of frustrated hours in front of the computer. You can use the extra time to actually reason about higher level problems than simple implementation details.

Note: if you are developing any sort of framework, scratch anything that I mentioned above. Almost NONE of the points in application development apply to framework development. A great deal of care and planning must go into framework development that cannot be covered with a simple bullet list. I strongly suggest using Framework Design Guidelines as a sanity check tool.