4 ms·
> we no longer use engineering as a means to an end to solve a business problem. Instead, engineering became its own thing I hadn't though about why we over-en
by naringas 7y ago
> we no longer use engineering as a means to an end to solve a business problem. Instead, engineering became its own thing
I hadn't though about why we over-engineer things this way. But I agree
I might add, based on the over-engineered (and, in general, badly designed) software I have worked with, that it usually comes about because it's never possible to change any aspect of the underlying architecture with the purpose of simplifying things.
We wind up with over complicated 'solutions' because we are simply unable to go back to simplify anything ever for any reason. The 'stake-holders' just don't think it's priority.
So all that's left is keep stacking clever solutions on top of bad decisions such that every new clever solution makes it even harder to go back to simplify.
- Nextgrid 7y agoIn my case the problem is less about changing things because the product became over-engineered after several years, and more about products starting out over-engineered because some idiot wants to put React and Kubernetes and "managing a large team" on his resume when the business problem at hand could be solved by a handful of PHP files sitting on a shared host (not saying you should go to such extremes, random PHP files and shared hosts are bad for other reasons).
- collyw 7y ago"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Antoine de Saint-Exupery
- jcbrand 7y agoIMO you should be spending time on refactoring and simplifying code without asking permission for it. Improving the code-base is part of the job and you should be setting aside about 20% of the time you estimate for new features to do so. There's no need to ask management for permission, your estimate is simply 20% larger.