4 ms·

Let me tell you a story about companies that often confuse thinking about the best solution with over-engineering... You get hired by this startup with great i

by iagooar 10y ago

Let me tell you a story about companies that often confuse thinking about the best solution with over-engineering... 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'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. The first change request comes in. Easy. It'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. 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'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/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. 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't even try to touch some of the code you wrote just a couple of months ago. "There be dragons" is, next to "TODO", the most used comment you find in the codebase. So after many days, the job isn't done yet. The mighty CEO gets nervous and starts running all over the place, giving you some "leadership". 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. There is 10 new bugs but you don'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't even have the time to think about how tired you are. Request 30 is going to arrive soon... But hey!, don'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... WAKE UP! THERE IS A BUG IN PRODUCTION!!! You need to rush. In the middle of the night, your messy apartment gets illuminated by the blueish light of your laptop. You don't even care anymore. The End --- Appendix By change request 40, your soul committed suicide. By change request 50, the company was spending 80% of their time doing bug fixes and keeping their self-build house of cards running. 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. 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. Finally, after all, you are happy again...

taneq 10y ago
That's not a story of under-engineering, it's a story of letting management push you into ignoring good practice. By change request 10, the prototype should have been extensively refactored and should look much more like a production system.
Udik 10y ago
> The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. Except that the messy project you were working on before sounded like a one man project. And at every new change request you delivered, working by yourself, a pretty big chunk of value. Now, in the nicely engineered project, you work in a team. The team is iterating in sprints that require a number of developers two or more weeks of work to deliver the tiniest feature. Yes, iteration is quick, but it doesn't really deliver much value. Every time the new CEO requests something even slightly different from the exact functionality that was developed so far, the project architect's answer is that this will not fit in the current set of features, and it might be possible, if ever, after another series of sprints that will take multiple months to complete. And the funny thing is that, while in your one man project you were considered a lone cowboy working on a relatively simple system, the architect of the current project (that delivers more or less the same functionalities but requires 5 or 6 times the time and resources to maintain) is considered a demi-god "because the project is so complex". Because of course the CEO measures the complexity of the project not but what it delivers, but by the amount of resources consumed by it. And while the CEO of the previous company was annoyed when a new feature required more than a week to implement all by yourself, now whenever the new architect says "we need more resources for that", this actually increases his power and consideration in the company, as it is taken as a sign of the complexity of the project.
fagnerbrack 10y ago
This will probably make a very good "storytelling like" medium post.
clusmore 10y ago
Nice story. I understand the point of the article, that there is such a thing as over-engineering. But as your story illustrates (and we can all attest to), there is also such a thing as under-engineering. I think the really insightful commentary is on which techniques typically fall into which category.

by iagooar 10y ago

taneq 10y ago

That's not a story of under-engineering, it's a story of letting management push you into ignoring good practice. By change request 10, the prototype should have been extensively refactored and should look much more like a production system.

Udik 10y ago

> The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. Except that the messy project you were working on before sounded like a one man project. And at every new change request you delivered, working by yourself, a pretty big chunk of value. Now, in the nicely engineered project, you work in a team. The team is iterating in sprints that require a number of developers two or more weeks of work to deliver the tiniest feature. Yes, iteration is quick, but it doesn't really deliver much value. Every time the new CEO requests something even slightly different from the exact functionality that was developed so far, the project architect's answer is that this will not fit in the current set of features, and it might be possible, if ever, after another series of sprints that will take multiple months to complete. And the funny thing is that, while in your one man project you were considered a lone cowboy working on a relatively simple system, the architect of the current project (that delivers more or less the same functionalities but requires 5 or 6 times the time and resources to maintain) is considered a demi-god "because the project is so complex". Because of course the CEO measures the complexity of the project not but what it delivers, but by the amount of resources consumed by it. And while the CEO of the previous company was annoyed when a new feature required more than a week to implement all by yourself, now whenever the new architect says "we need more resources for that", this actually increases his power and consideration in the company, as it is taken as a sign of the complexity of the project.

fagnerbrack 10y ago

This will probably make a very good "storytelling like" medium post.

clusmore 10y ago

Nice story. I understand the point of the article, that there is such a thing as over-engineering. But as your story illustrates (and we can all attest to), there is also such a thing as under-engineering. I think the really insightful commentary is on which techniques typically fall into which category.