How to Accept Over-Engineering for What It Really Is
Let me tell you a story about companies that often confuse thinking about the best solution with over-engineering...<p>You get hired by this startup with great ideas. They have really hit their niche nicely and are getting more and more customers. You build a great throwaway prototype and customers and the mighty CEO love it. You ask when you are going to rebuild the prototype, since it&#x27;s a bit of a mess... The hipster CTO says that there is no need, that you are the greatest dev ever and that he will get a tattoo with your name.<p>The first change request comes in. Easy. It&#x27;s still straight-forward to make some quick and dirty changes here and there. You call it a day and your hipster CTO throws a party to celebrate the amazing job.<p>After change request 10, you feel like slowing down drastically. The mental model you could fit in your brain until now, is too complex. You can&#x27;t touch all the involved parts of your application anymore or it would cost you a lot of time. You get away with some if&#x2F;else statements to fix the edge cases. You feel happy again, you did it! You call it a day, your hipster CTO pats your back and gives out some beers.<p>After change request 20, the system is a mess. Different layers of the application talk directly to each other, thus creating painful coupling. Your abstractions are either non-existent or all in the wrong places. You have no CI, because that would have been over-engineering the test suite. Your local tests take half an hour, because making them run in parallel would have been over-engineering. The time for documenting the project was spent hunting quirks somewhere in the darkest places of your application. You don&#x27;t even try to touch some of the code you wrote just a couple of months ago. &quot;There be dragons&quot; is, next to &quot;TODO&quot;, the most used comment you find in the codebase.<p>So after many days, the job isn&#x27;t done yet. The mighty CEO gets nervous and starts running all over the place, giving you some &quot;leadership&quot;. He says that there is a deadline not to be missed or the universe will collapse. The hipster CTO even has to skip his yoga-classes to meet the deadline. After many extra hours and even more energy drinks, you get the change request done. The hipster CTO just smiles at you, but no beer this time.<p>There is 10 new bugs but you don&#x27;t know about them yet. Soon you will, because people will start complaining about that last change you did and the bugs you introduced. By this time, you are sick and tired of it all. You hate yourself. You feel guilty. Problem is, you don&#x27;t even have the time to think about how tired you are. Request 30 is going to arrive soon...<p>But hey!, don&#x27;t forget that you HAD TO ship it quick, not think about solving the problem! Abstractions? Over-engineering! Designing for resilience? Over-engineering! Small, independent services? Over-engineering! Staging system? Over-engineering! All these thoughts come to your mind everytime. Yet, you are so tired, you fall asleep and try to forget it all...<p>WAKE UP! THERE IS A BUG IN PRODUCTION!!!<p>You need to rush. In the middle of the night, your messy apartment gets illuminated by the blueish light of your laptop. You don&#x27;t even care anymore.<p>The End<p>---<p>Appendix<p>By change request 40, your soul committed suicide.<p>By change request 50, the company was spending 80% of their time doing bug fixes and keeping their self-build house of cards running.<p>By change request 60, there was this tiny competitor who gathered together a nice little team of skilled and motivated engineers. The CTO would give them time to think about how to solve the problems best. Soon they entered the market at an amazing pace. All competition went out of business. You lost your job. You have no motivation. You feel lonely.<p>By change request 70, which never actually happened, that tiny competitor sees you as a valuable asset to their company. Since they are growing, they need people like you, with experience and skills. You still feel like the worst developer ever, but you take the job. People respect you. The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. People share their ideas and with each iteration they make it better.<p>Finally, after all, you are happy again...