Have you ever encountered an over designer? An over designer is a software developer that had some life changing event and became obsessed about architecture. The result being, obsessive decoupling, endless coding of Factories, creating deep (also needless) inheritence hierarchies and various use of design patterns for no good reason.
I believe the over deisgner is a mutation in the natural evolution of a software developer.
Software Developer’s Evolution
Not every software developer reaches to Senior level. Few reach to Jedi Master and some rare geniuses evolve to Jon Skeet’s level.
I believe somewhere during the transition from Code Monkey to Senior a mutation occurs: The Over Designer.
Mutation causes
- Reading a book like Clean Code
or seeing some video and taking it too literally.
I read this book and it completely changed my perspective on software design. I now realize we were doing it all wrong.
(By the way, I love Clean Code!) - Working with poorly designed code.
Usually legacy code is poorly designed. The reason being is we add more and more features without refactoring, which makes the code more coupled, which in turn makes it even harder to refactor and even more legacy.
The logical assumption being that initial poor design is the reason of all evil. Leading to over designing. - Over confidence. Unfortunately, the Over Designer mutation happens to the best of us. When we work with weaker developers and tend to know more than others, we start to think we are always right and stop doubting ourselves.
Mutation symptoms
- Preparing for future developments. This is when we are asked to develop a feature and instead end up developing an infrastructure for similar features.
For example:
Joe was asked to write the time in a HH:MM:SS format. This might seem like one line of code but unfortunately Joe is an Over Designer.
Joe created an interface ITimeFormatter, a class TimeFormatterHHMMSSImplmentator and a Factory TimeFormattingFactory. - Using design patterns everywhere. Usually happens right after reading a book on design patterns
- Simple tasks turns into complex developments. Over designers are able stretch one-hour tasks to days or even weeks of work.
- Obsessive decoupling. Over designers tend to create classes and class libraries with abandon. Explaining this by a need to add abstractions and to decouple.
Summary: Let’s Design, but not Over Design
Our job in software is first of all to get the code to do what the customer wants. We also need to make our code reliable, expandable and testable. And with the least amount of complexity.
Programmers are notoriously bad at guessing what the next feature will be. Please, let’s not create infrastructures for features that might never come.
I suggest always doing the minimum to get the immediate task done. Following the KISS principle . But, we have to keep our program decoupled and testable as well. We can follow these 2 simple steps:
- Develop the immediate task as simply as possible
- Refactor the code so the additional code keeps our system decoupled, expandable and testable. But keep the refactor as simple as possible.
Of course, if we are planning a big system and we know in advance what it should do, we should plan our design ahead and not break the system into a list of features, developing one after the other as simply as possibly. That would be madness.
