Think twice before changing a design

You’re required to implement a system, and you receive an already created design. You get one or more class diagrams, maybe a sequence diagram too. Perhaps you’re lucky and you even get an architectural diagram. You’re a great designer and you won’t start the implementation before understanding it and verifying that it is correct.

You get the overall idea and it looks correct but it is just horrible. Well, it seems to work but it is obvious that there are some ways to design the same thing that are much better. You’re tempted to make it simpler, more elegant and to implement design patterns that perfectly fit for that situation.

Don’t do it unless you really know what you’re doing.

I’m not talking about becoming an over-conservative-passive-just-in-case-I-would-not-change-it software designer. Not at all. You should always be proactively thinking about how to improve what is already done. However, there might be serious reasons behind for the original designer to do it that way. How about if:

  • There is another piece of code depending on this API.

  • Some non-functional requirement is so critical that you need to imperfect the design to boost that aspect.

    • Think about performance. Perhaps this particular piece of code is going to be executed a huge number of times per second and it has to work really fast. Maybe reutilizing an object or not calling a third method to avoid stacking execution frames could become a good idea. Non-functional requirements have to be considered before creating the design.

  • Your design is more elegant and flexible but it would require 15% extra time. Well, 15% for a much better design? Worth doing it! Maybe not. There may be critical commercial reasons to deliver the product earlier. Even having to pay that cost. You will increase your technical debt and it will have to be paid sooner or later, but maybe this time, it really has to be later.

  • The new design is built on top of an already existing piece of code or framework. That dependence might be so critical and/or buggy that the company does not want to take the risk of changing it. You could wrap it, abstract it and improve the design. However, don’t make that assumption unless you are familiar with the creature.

Now you might be thinking “I understand but how do I know?”. Ask.

The original designer should have included a Rationale in the design explaining assumptions, compromise decisions and trade-offs, but maybe he or she didn’t. There are rare examples of great software built by heroes but it is plenty of fantastic products created by teams with good technical skills but better communication capabilities.

To sum this up, all the software designs have the same level of quality, at prior. Once you know what they are for and the context in which they were created, you can evaluate them.