Poorly Finished Basements in Software Development

Several years ago when I was looking for a house to purchase, I saw several otherwise attractive homes that I decided against purchasing after seeing the badly finished basements. These finished basements were turn-offs for a variety of reasons such as 1970s paneling and/or carpet, cheap materials, bad and/or strange layouts, and so forth. An alluring aspect of purchasing a new house can be the chance to have the basement finished exactly as one would want it. When the basement is already finished, it may be less like what one would want. It is more work to fix the existing finished basement by tearing things down and rebuilding than it would have been to build it in the first place. Of course, there is the relatively rare situation when one is fortunate enough to find a nicely finished basement that is close to or exactly what one wants. This can be preferred even over an unfinished basement because the work is already done, done well, and satisfies the desires of the purchaser.

Working on software development projects can sometimes feel like buying a house. The unfinished basement is like a greenfield project where anything is still possible, but will require effort and skill to accomplish grand visions. The poorly finished basement is like a badly written piece of software that is difficult to read and maintain. Just as even a reasonably nicely finished basement may not offer a potential home buyer what he or she wants in a basement, a relatively well-done piece of software may not meet customer expectations of certain features (and more likely will suffer some Not Invented Here Syndrome effects from developers). On the other hand, in a relatively small percentage of cases, customers and developers may find that the existing code being reused is so well done that they don't feel the need to refactor it. In these cases, the software is extremely valuable for its features and quality.

My realtor pointed out that certain features of a finished basement are easier to change than others. For example, it is easier to put in new floor coverings (carpet, tile, hard wood flooring, etc.) and to paint than it is to change layout (changing plumbing location or locations of walls). The use of existing software is similar. Some aspects of maintaining and reusing existing software are easier to improve than others. For example, it is generally easier to improve the names of variables, method names, and other structures than it is to make significant architectural and design changes. In both software development and house buying decisions, it is important to realize that not all problems with existing product are of the same difficulty to improve. Just as one might buy a house with a finished basement of reasonable layout but outdated carpet and paint, it is often worth the time and effort to improve the "little things" that make existing code less maintainable than it otherwise might be.

There are times when one buys a house with a really badly finished basement because there aren't many other choices. For example, the location of the house of the rest of the house may be so attractive that the buyer feels the deal is worth taking even with the poorly finished basement. Similarly, we run into situations in software development where we must deal with and improve badly crafted software because the features of the existing software are too compelling to ignore. Reasons for this could include the high cost of completely rewriting the software, the inability to completely rebuild the software, and so on.

The worst basements that I saw were the ones that had crazy, maze-like layouts as if the basement was built without any planning or design. The worst software feels very much the same. When I saw the worst of the finished basements, I realized that I'd probably end up tearing down large portions of the finished basements to rebuild them in an improved fashion. The worst software is similar in the sense that it too often must be completely torn down and rebuilt if it is too badly implemented.

The other side of this discussion is what we can do as the sellers of the house or developers of the original software to make our products more interesting to potential buyers and developers. As a home owner, we can spend time and resources to carefully design a generally appealing and useful basement that adds value to the house rather than detracting from that value. Similarly, in software, careful design and forethought can lead to better planned and more readable software. With both basements and software, we also need to be prepared to undo (refactor) some of our work if we realize we have made a mistake. For example, the homeowners with the maze-like basements should probably have been more willing to tear down and change walls to have a more useful and desirable basement.

One of the characteristics of some of the unappealing basements I saw was the inclusion of specialty features that I was not interested in. Undesirable features clouded my vision of how the basement might be used and, at best, were seen as something that would have to be tolerated or removed with additional effort. Similarly in software, we can make our code more attractive to those who wish to maintain and reuse it by using established practices, avoiding being too clever, and adding producing code that is generally pleasing.

A poorly finished basement can turn away even the most interested potential buyer. Similarly, poorly implemented code can turn away the most enthusiastic software developer. Most software developers I know prefer to work on completely new projects. However, a close second is to add to or enhance a well-written existing code base. It is usually far less exciting to try to band-aid a poorly written piece of code and it is often very tempting to tear it down altogether and start over. However, just as it is for the homeowner who tears down and rebuilds a basement, this is both expensive and time-consuming.