3 ms·

The bottom line is that whether something is "over-engineered" or not can mostly only be confirmed in hindsight. With experience and instinct, some people are

The bottom line is that whether something is "over-engineered" or not can mostly only be confirmed in hindsight. With experience and instinct, some people are successful more often than not in predicting what level of engineering is sufficient, and they go on to become great engineers and leaders. But I am not wholly sure if this is more skill or more luck, though I am sure there is some skill. With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount of flexibility you need. When designing a common utility or infrastructure piece to be used by everyone in a large company, it is much less obvious. But I think the hardest layer is the mid-tier, which has to deal with the backend and the frontend, and support all kinds of changes and pluggability.

mewse 10y ago
I would argue that it's more skill, but not engineering skill. It is more a social skill; being able to read the work environment the software will exist inside, and predict the likely ebb and flow of development requirements. To have enough experience with the people involved to know how much flex a given system will have to undergo, over time.
wvenable 10y ago
Not fearing change and being able to handle change is the skill required; and it can be learned from experience. An over-engineer will attempt to build a system that is too flexible and too complicated in order to mitigate all possible changes. Similarly, an under-engineered project will become of patchwork of impossible to maintain code when the changes roll in. The skill is knowing how to evolve a project -- create new abstractions and layers -- in the face of change. To fundamentally alter the product and keep it working all at the same time. If you under-engineer a project and you don't know how to do this eventually you'll be faced with the dreaded re-write. Throughout history how many companies and products have failed because of that. If you over-engineer you can suffer with a huge amount weight you don't need. And even then you still might get it wrong and be stuck with an architecture that doesn't work given new requirements -- which might require an even more difficult re-write. So many engineers can't bring themselves to remove code or change their architecture; so they try and get it right the first time.
- mmazing 10y ago
  > Not fearing change, being able to handle change is the skill required Agree x1000, I'm currently dealing with a situation stemming from this sort of thing (not being able to handle change, in software design, and philosophically with the architecture). I also keep using the term "evolve" with respects to how to develop a good codebase. You can use design pressure to drive abstraction and logical components of a codebase. If you try to figure all that out from the start, you're going to have a bad time.
crdoconnor 10y ago
>With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount of flexibility you need. When designing a common utility or infrastructure piece to be used by everyone in a large company, it is much less obvious. There's a relatively straightforward approach to this that works well - simply don't build in flexibility until it's explicitly required or it's very, very obvious it will be required. When you're engineering mid-tier and back end the requirements can be most easily ascertained by doing the upper levels that depend on them first and working your way down. I'd estimate that 9 out of 10 times when an engineer tries to predict and pre-empt future requirements they fail and that failure is often expensive not only in wasted time but in useless extra code to confuse maintainers (and new space for bugs to grow in).
georgeecollins 10y ago
The problem in my experience is that the pain of unanticipated change, or poor early engineering choices is felt acutely by programmers (sorry, I am going to call them that). It is really annoying to work with ill suited code. It is demoralizing to rewrite code. Programmers want to write code that lasts and hate when the code they wrote is unsuitable, as a matter of professional pride. But the pain of over engineering is felt less acutely. Delays and confusion are often not realized in the moment. When the negative feedback comes it often comes from the 'other', a manager or another engineer who doesn't understand.
- Drdrdrq 10y ago
  Pain of over engineering might be more hidden and difficult to point at, but in my experience it hurts much more. At least with under-engineered code you know what to do... But will you ever be able to remove unnecessary abstractions?

mewse 10y ago

I would argue that it's more skill, but not engineering skill. It is more a social skill; being able to read the work environment the software will exist inside, and predict the likely ebb and flow of development requirements. To have enough experience with the people involved to know how much flex a given system will have to undergo, over time.

wvenable 10y ago

Not fearing change and being able to handle change is the skill required; and it can be learned from experience. An over-engineer will attempt to build a system that is too flexible and too complicated in order to mitigate all possible changes. Similarly, an under-engineered project will become of patchwork of impossible to maintain code when the changes roll in. The skill is knowing how to evolve a project -- create new abstractions and layers -- in the face of change. To fundamentally alter the product and keep it working all at the same time. If you under-engineer a project and you don't know how to do this eventually you'll be faced with the dreaded re-write. Throughout history how many companies and products have failed because of that. If you over-engineer you can suffer with a huge amount weight you don't need. And even then you still might get it wrong and be stuck with an architecture that doesn't work given new requirements -- which might require an even more difficult re-write. So many engineers can't bring themselves to remove code or change their architecture; so they try and get it right the first time.

mmazing 10y ago
> Not fearing change, being able to handle change is the skill required Agree x1000, I'm currently dealing with a situation stemming from this sort of thing (not being able to handle change, in software design, and philosophically with the architecture). I also keep using the term "evolve" with respects to how to develop a good codebase. You can use design pressure to drive abstraction and logical components of a codebase. If you try to figure all that out from the start, you're going to have a bad time.

crdoconnor 10y ago

>With software, it is especially hard. Especially as you go deeper and deeper into the components. At the UI level, it might seem easy to say what is the amount of flexibility you need. When designing a common utility or infrastructure piece to be used by everyone in a large company, it is much less obvious. There's a relatively straightforward approach to this that works well - simply don't build in flexibility until it's explicitly required or it's very, very obvious it will be required. When you're engineering mid-tier and back end the requirements can be most easily ascertained by doing the upper levels that depend on them first and working your way down. I'd estimate that 9 out of 10 times when an engineer tries to predict and pre-empt future requirements they fail and that failure is often expensive not only in wasted time but in useless extra code to confuse maintainers (and new space for bugs to grow in).

georgeecollins 10y ago

The problem in my experience is that the pain of unanticipated change, or poor early engineering choices is felt acutely by programmers (sorry, I am going to call them that). It is really annoying to work with ill suited code. It is demoralizing to rewrite code. Programmers want to write code that lasts and hate when the code they wrote is unsuitable, as a matter of professional pride. But the pain of over engineering is felt less acutely. Delays and confusion are often not realized in the moment. When the negative feedback comes it often comes from the 'other', a manager or another engineer who doesn't understand.

Drdrdrq 10y ago
Pain of over engineering might be more hidden and difficult to point at, but in my experience it hurts much more. At least with under-engineered code you know what to do... But will you ever be able to remove unnecessary abstractions?