“If it’s complicated, then it’s wrong” — Me!

I have said the above phrase to a lot of people in my quest for writing good software. Sometimes people get it. Many times people just smile and say “OK”, but they don’t really understand. The “OK” repsonse happened just the other day and I decided to attempt to explain my reasoning.

The main concept in my mind is the following: There are many business processes that are complicated (that’s a different story - we’re talking about software for now). A complex business process does not mean that the supporting software needs to be complicated as well. I constantly find that the complexities of a business process get duplicated in the design of the software. And the typical verbal defense for the complicated software? Well… the business process is complicated.

Hogwash. Don’t let a business process dictate the design of your software. Abstract things out. Look for patterns and apply them. Encapsulate things that are complicated with simplified interfaces/wrappers. Document and unit test your code along the way. If it’s difficult to document or unit test, then maybe it’s too complicated to begin with. If the software is difficult to follow, that’s the designer/developer’s fault - not the business process. Please don’t use a complicated business process as a justification for your complicated spaghetti code.

The flip-side can also be true. If the software is getting difficult because of the business process, then maybe the process should change. But that is a different topic, and not one that a developer has control over. So take control of what you can (the code) and at least make things better for yourself.

This entry was posted on Thursday, January 25th, 2007 at 10:03 pm and is filed under Software Design. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.