Making Good Software

The simpler the better

The simpler the better, that’s something that we usually forget when we are developing software, lots of times we are tempted to use design patterns/frameworks/technologies/tools… without considering other simpler and less fancy options. If there are two ways to implement something and if they are equally functional and don’t add any repetition to your system, pick the simplest solution.

Considerations for not adding complexity to your project

If all you have is a hammer, everything looks like a nail

This is a common bad habit in developers that have just learn something new and they are anxious to apply it. Suddenly everything fits this new technology/tool/framework… Here are some examples:

• ESB: “Let’s communicate the backend layer and the UI layer of this desktop application through the ESB!!!
• Spring: “I have to create the class car, and it has 4 doors, I will better assign that dependency through Spring!!!!”

Because you can, it doesn’t mean you should

This is common in senior developer that are eager to show how advanced their designs can be. Example:

• Abstraction: “The board class for this chess game software is too rigid. I will change it so that it will be a dynamic 2D grid which will allow us to create chess boards of 12*12, 4*6, or any other arbitrary dimension”

The more things that can fail, the more things that will fail.

There’s something that every developer must always remember. We always make errors. The number of errors we make is proportional to the number of things we develop and their complexity. So the safest path is not to write code at all or not to add complexity.

The more prepared is your code for change, the more difficult is to change your code.

This is a paradox which I believe I read in a Kent Beck book, (I think it was in “Xtreme programming explained”, if someone could please confirm this in a comment I will appreciate it very much).

It is a common scenario when a developer proudly shows some code and explains that because of his design, any future changes related with his class can be handled through configuration. Three months later, the first change request not only shows that the current code needs to be changed, but because of over-engineering, extra effort in refactoring is going to be necessary.

Add complexity if… makes things easier!

I hope I am not sending the wrong message with this post, I’m not saying that using frameworks/tools/new technologies… is bad, I’m saying that if not used appropriately the complexity they bring takes over any flexibility they may offer. So the key is to know when to use them. Here you can find three tips that may help you.

Use them to get rid of some duplication you have in your code.

This is one of the most legitimate causes to add a tool/framework/technology to your project, duplication makes your code maintenance a nightmare.

Use them because of the flexibility they provide

Spring, Hibernate and other frameworks are examples of frameworks that are great when you need flexibility.

Use them because is easier to use them than to implement their functionality by ourselves.

If you need a unit testing, don’t write your own, use any of the xUnit or TestNG, for example.

Wether Software development is an Engineering or a Craftsmanship is one of the hottest topics in the software development community, and it generates many articles and opinions as these two articles which have been brought to my attention lately and which I highly recommend you to read.

• Tom DeMarco.  (Author of  Peopleware: Productive Projects and Teams)- Software Engineering: An Idea Whose Time Has Come and Gone? (PDF).  “My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.” Saw in codinghorror.com
• Charles Fishman. They Write the Right Stuff. (An article about the software developed by NASA). “[...] This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, [...]each 420,000 lines long-had just one error each.[...]How do they write the right stuff? The answer is, it’s the process. [...]The product is only as good as the plan for the product.“

So who is right, Tom DeMarco, or the NASA, well, I wouldn’t dare contradicting any of them, I actually believe they both are right! What is wrong is the question: “Software development: Engineering or Craftsmanship?”. There isn’t an unique way to go, they can be both applied, is just a matter to identify which approach suits better to the software that has to be developed.

So… what approach to use in each case: Engineering or Craftsmanship?

Most commercial projects can’t simply cope with an Engineering approach, can you imaging building an e-commerce site that has to be fully specified and designed upfront with no changes after and without early feedback? I don’t think so, what is amazing is that there are still some companies that try to use an Engineering approach (most usually waterfall) to develop this kind of software. Waterfall only works if you follow all of  its steps and if you don’t make any change to the specifications when you start coding, when a waterfall project fails, most of the times is not because waterfall is wrong but because waterfall doesn’t adapt to the type of software they want to build, Waterfall doesn’t work with software that evolves while it’s been build, for these cases is better to follow a craftsmanship approach.

Craftsmanship approach characteristics

• Specification and design are created in an on-going basis.
• Gives plenty of  room for change.
• Focus on people and communication.
• Early feedback.
• High rate of errors, but the application is functional.
• Uncertainty on how the final product will be.

For some other companies what is essential is that there are no surprises and that the software doesn’t have any errors at all, that’s typical from critical systems as Aircraft software, Rocket software, Trains software… In this case an engineering approach is essential.

Engineering approach characteristics

• It requires full specification and design beforehand.
• Focus on processes and contracts.
• It does not allow room for change.
• Late feedback.
• No surprises.
• No errors (Almost).