Software Development Faux Pas: Design by Deja Vu

Software design and implementation is still very much an art. This is not surprising when you consider that mankind, with the exception of a few individuals like Charles Babbage, has only been writing software for about 70 years. That, however, does not excuse some of the faux pas made in the name of "Software Development".

Design by Deja Vu

Imagine, if you will, that you are writing some code one day and you think, "Hey, I've done something like this before." You search through the code base and you find another instance of the "same sort of thing". You feel that this is an opportunity for reuse, so you strip out the common code and put it into some utility library so it can be reused in both places. I call this Design by Deja Vu and although it may be done with the best of intentions, I think that it is very, very bad.

On the surface Design by Deja Vu seems like a good thing - after all, aren't we trying to achieve code reuse? Well, yes, we are trying to attain code reuse, but not in an ad-hoc, knee-jerk, retrospective, uncontrolled manner. Let's replay the situation and see what the Naked Chef type of developer would think...

Imagine, if you will, that you are writing some code one day and you think, "Hey, I've done something like this before." You search through the code base and you find another instance of the "same sort of thing" and you instantly think, "I wonder what's wrong with my design and how I ended up in this situation." You then spend a little time reasoning about the software design, get it straight in your mind and then implement the required changes - which in many instances will be exactly the same changes implemented if you just designed by Deja Vu!

If both approaches often result in the same code being written, what's the big deal?

Implementation follows Design

What's the big deal? It all boils down to not following the right software design principles. Following principles such as the Open/Closed principal are known to lead to good, SOLID software. However, if you have not applied these principles through your code, it is horrendously difficult (read expensive) to try and retrofit a good design in an incremental fashion. This inevitably leads to ditching the big ball of mud and starting from scratch.

By the time you are in a position to Design by Deja Vu, a serious mistake has already been made. However, it may not be too late to recover and fix the problem with a well thought out design. Sometimes you find that the code duplication is a symptom of a bigger problem; if you blindly go ahead and strip out the common code, the underlying problem remains unfixed and your code descends further towards being a big ball of mud.

On the other hand, if you take the standpoint that the duplicate code smells like a serious design error may have been made, then two things will result. Firstly, you know that what ever you end up changing will be treating the cause of the problem, not merely a symptom. Secondly, you will grow as a developer and be in a better position to avoid the situation happening in the future.

I am a firm believer that implementation (ie, the code) follows design. That is, the code is merely an expression of my design. When you Design by Deja Vu, your design is dictated by your implementation. This is just plain backwards. This is not to say that I promote a top-down approach to software design and implementation - the name of my company, Think Bottom Up, shoud make that clear. Rather, that uncovering a design problem is a good trigger for an iteration in the development process - revisit the design before continuing with implementation.

Bringing it Home

The thing that I don't understand is that (just about) every developer you speak to will tell you about "best practices" and how design principles and modern development methodologies lead to high quality products, and yet in practice, the vast majority of code bases become a big ball of mud in the end. Is it just that developers don't stick to their guns when faced with time and budget pressures? Or is it that we still have no idea how to write software? Or is it that we just don't aspire to "do better"?

If you haven't read about the big ball of mud, then you best do so. It's essential reading not just for developers, but for managers and marketing types too.