How To Accept Over-Engineering For What It Really Is
Fagner Brack

There is another motivation for over-engineering that I have encountered. Aside from an attempt to add value to the system, at times it is done to add apparent value to the system. I worked on a part of a gigantic system. It was due for a major refresh. A $1 billion+ contract was awarded. The largest part of this system would have been well served by an off-the-shelf solution which already existed and which was designed for exactly the use it would be put to. Instead of using that, however, the contractor dismantled the off-the-shelf solution, took one component of it, and proceeded to spend several years building a replacement for the rest. What resulted was the most convoluted ball of (you guessed it) Java code I have ever seen. As the existing developers and maintainers were introduced to it (of course they used an external contractor, not the people who had been working on the system for a decade) we discovered that the biggest problem was finding code that actually DID something. It was like ordering a toilet and receiving an entire hangar with a bucket in it (a bucket with a hole… it didn’t even compile when delivered).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.