Concrete symptoms of over-engineering
I have recently found myself in the position of explaining an (In-House) application I have written to two candidates my company likes to hire in order to assist in maintenance and adding minor features.
It is the first "production" application I have written, it has 45k LOCs and I spent almost two years of "solo" development on it. I am fairly young (18) and wrote the application from scratch while being contracted as stand-in for a former developer who left the company. Unexperienced in designing applications of this size, I tried to use common architecture- and design-patterns.
Today I know I have done some serious over-engineering, e.g. using a disconnected change tracking architecture instead of the Unit Of Work pattern, which the chosen ORM has already implemented. I will probably never have to go "real" three tiers.
Both candidates have 10 years+ background in In-House Application Development with the relevant platform. Being half their age and having little experience I do respect their opinion. When I was explaining the application architecture to them, comments were along the lines of:
- Jeez, no one would pay me to do stuff like that, I have to get things done
- Stick with what the framework does, don't use fancy libraries/technologies
- Don't wrap framework code. On a team, everyone will write his own wrapper code anyway.
- You're using .NET 3.5? Well, we are using 2.0.
- What does that LINQ stuff buy me? All this query composition and projection seems too complicated.
Now I am asking myself:
Am I an architecture astronaut? How do I know I am going too far with architecture? What are common symptoms of over-engineering?
Answer
What are common symptoms of over-engineering?
Code that solves problems you don't have.