More Thoughts On Software Development

Flying Blind

Too often commercial applications software is implemented with very little in the way of good requirements or design documentation. To be fair, the code occasionally shows that, at least initially, some thought did go into the design (this is assuming that one can actually see the source code–often that it not the case). But at some point it went off the rails and never came back. The end result (at least 30 to 70% of the time, depending on who you ask and what the definition of “fail” happens to be) is software that is buggy, bloated, difficult to use or just plain broken. In other words, it’s a failure.

It has been my experience that this type of scenario seems to occur most often in smaller shops (with 1 to 10 developers). People get busy, they’re under pressure to write code not documents, marketing drifts in with a wish-list that they think needed to be implemented yesterday and so on, and so on. Still, to be fair, I’ve also seen this in situations where there was no rational excuse for it to have occurred. Such as in the software that actually flew on a space mission back in the late 1990’s. It was stunningly bad, and it was obvious from examining it that very little design guidance went into it, and because it actually made it out the door and onto the vehicle it was also obvious that very little review took place.

When processes are lacking, or if they are not utilized, the result just can’t be good. Without requirements how does one know how the software is expected to behave? How can it be tested if there is nothing to determine what constitutes pass or fail criteria? Without a design document how can one know when enough is enough, or when it’s too little, or if it’s even the best choice to tackle the problem? Just flail around? Whack and hack and see what works? Ugh.

Implementation without design guidance is universally acknowledged in the industry as a Really Bad Idea. This type of scenario is also cited numerous times in the literature as a common reason why software projects fail. One cannot simply start with a vague (or nonexistent) functional description and hack a path to paradise. It can also be extremely wasteful in terms of time and resources.

Throwing Money Away While Looking Busy

And speaking of wasted time and resources, I once reviewed the code used in a commercial product and was amazed to find huge chunks of it commented out. It was obvious from reading through the code that considerable time was wasted writing sections that were later tossed out due to the top-down trial-and-error implementation approach employed. Not only did these useless sections of unused code clutter up the source, they also indicated to me that there were implicit behaviors that were not well understood, and in most cases not even documented. What errors would these cause in the future? But, even worse in my opinion was the obvious fact that someone had spent considerable time working down blind alleys and then giving up in order to try a new approach. How much time and money was wasted while they fumbled around?

Does It Work? Can You Prove It? Really?

Without robust testing there is no way one can assign any significant level of confidence to code. When there is almost no testing support to speak of, and any so-called “unit tests” that are implemented in the code are not documented or justified (because there are no requirements to trace back to, obviously), then it is unclear that the unit tests actually do anything more than provide a test of functional behaviors and exercise the compiler. Critical aspects such as boundary conditions and error handling must be addressed, and they can only be addressed if there are some kind of requirements that define what the boundary and error conditions actually are. The bottom line here is that without requirements and test cases to justify and document the unit tests they are not useful or informative.

Would You Trust Your Own Product?

If they built cars like many folks build software, would you want to trust your life to one while zipping down the freeway at 70 MPH? If you commute to work you do it routinely, and probably without thinking about it. How about when you fly across the country? Do you feel good about the way the aircraft was designed, assembled and tested? Will you arrive safely or end up as a greasy spot in a cornfield somewhere in Kansas? When writing your thesis, or creating a winning proposal that’s due tomorrow, don’t you want to trust that the computer won’t suddenly go belly-up and throw your work on the floor? Can you afford to take the time to try and recover what you would lose if that happened?

Complex devices like aircraft, automobiles, computers and even washing machines are not assembled by grabbing likely-looking parts from a bin and seeing which ones seem to fit, so why should complex software be treated as an ad-hoc exercise?

Advertisements

0 Responses to “More Thoughts On Software Development”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: