3 ms·

I’ve never liked the term over-engineering. People seem to use it as an excuse for pre-mature pessimization. The cost of not forward thinking about architectur

I’ve never liked the term over-engineering. People seem to use it as an excuse for pre-mature pessimization. The cost of not forward thinking about architecture is that companies and teams can wallow in a land of low productivity while they try to evolve an architecture that wasn’t thought through. Obviously you need to be aware of your market - for example, an app for local real estate doesn’t have to scale to billions of users per city - but there are common patterns that will scale up well for almost all companies.

throw-away-8 9y ago
It's much easier to produce quickly something horrible without much thought, report it to manager as done, be seen as "gets shit done fast" and get promoted than to take time and effort to do well thought through scalable and reusable things and accept consequences of thanklessly taking time and expending effort.
jstimpfle 9y ago
So you have skipped the overzealous abstraction stage in your personal evolution as a programmer? I don't have, and I'm sensitive to this. I might have a tendency to rant about it even before I can see it, but it's a very real problem.
- mindvirus 9y ago
  I have made a ton of mistakes for sure. But at almost every place I've worked, under-engineering has been a much more pervasive problem than over-engineering. And so over-engineering is often used as an excuse not to do engineering to begin with. Building a Rube Goldberg machine to solve a simple problem, or reinventing the wheel poorly isn't over-engineering -- it's just bad engineering. That said, a term I do agree with is YAGNI, which I think is much more concrete and well defined.
  - jstimpfle 9y ago
    Well said!
iamcasen 9y ago
I agree whole-heartedly. Every place I've worked, I get the side eye whenever I talk about how the patterns being used are dangerous, and will only get us so far before we have to re-write everything in a panic to handle a new use-case for a customer. It's something that took me a long time in my career to understand: businesses care about profits, and since we are all salaried, they don't care if we have to work ridiculous hours patching a buggy, shit system. They just want to get a polished turd into the hands of customers ASAP. On one hand, I get it. Why build the worlds greatest system, and design it so well that it will never fail, and it will scale effortlessly, and it will be easy to add new features indefinitely? That will likely take 3 or 4 times longer to bring to market, and if the value proposition doesn't add up, it's not going to happen. So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc.
- taway_1212 9y ago
  There's lot of software written in non-tech firms to support the company's core business. The whole finance industry is like that for example. In my experience, they care a lot about quality and architecture (for example, in some of the projects I've seen there's more devops or automatic testers than developers).
- jstimpfle 9y ago
  There are a few things wrong here. Businesses do often (usually) care how many hours you spend patching "buggy, shit systems". Because programmers are expensive. Obviously. They do not care about meeting arbitrary, irrelevant standards, like extensibility for features they will never need. Because that's expensive, obviously. Meeting arbitrary unneeded goals even takes a toll on actually relevant goals, like being able to adapt software quickly. I don't understand how you think this would not be a worthwhile goal. > design it so well that it will never fail Too much black and white thinking. Most problem domains don't need "will never fail", but are ok with "fails only seldom". And meeting "will never fail" is extremely expensive, obviously. > So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc. A good architecture is one that helps towards actual goals. And that's not extreme extensibility or extreme correctness, in most cases. For a concrete example, think about a game engine. It will not meet most arbitrary goals you could make up (it will fail, sometimes, and it can't make your coffee). But still I hope you can agree that there are many really well architected game engines.

throw-away-8 9y ago

It's much easier to produce quickly something horrible without much thought, report it to manager as done, be seen as "gets shit done fast" and get promoted than to take time and effort to do well thought through scalable and reusable things and accept consequences of thanklessly taking time and expending effort.

jstimpfle 9y ago

So you have skipped the overzealous abstraction stage in your personal evolution as a programmer? I don't have, and I'm sensitive to this. I might have a tendency to rant about it even before I can see it, but it's a very real problem.

mindvirus 9y ago
I have made a ton of mistakes for sure. But at almost every place I've worked, under-engineering has been a much more pervasive problem than over-engineering. And so over-engineering is often used as an excuse not to do engineering to begin with. Building a Rube Goldberg machine to solve a simple problem, or reinventing the wheel poorly isn't over-engineering -- it's just bad engineering. That said, a term I do agree with is YAGNI, which I think is much more concrete and well defined.
- jstimpfle 9y ago
  Well said!

iamcasen 9y ago

I agree whole-heartedly. Every place I've worked, I get the side eye whenever I talk about how the patterns being used are dangerous, and will only get us so far before we have to re-write everything in a panic to handle a new use-case for a customer. It's something that took me a long time in my career to understand: businesses care about profits, and since we are all salaried, they don't care if we have to work ridiculous hours patching a buggy, shit system. They just want to get a polished turd into the hands of customers ASAP. On one hand, I get it. Why build the worlds greatest system, and design it so well that it will never fail, and it will scale effortlessly, and it will be easy to add new features indefinitely? That will likely take 3 or 4 times longer to bring to market, and if the value proposition doesn't add up, it's not going to happen. So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc.

taway_1212 9y ago
There's lot of software written in non-tech firms to support the company's core business. The whole finance industry is like that for example. In my experience, they care a lot about quality and architecture (for example, in some of the projects I've seen there's more devops or automatic testers than developers).
jstimpfle 9y ago
There are a few things wrong here. Businesses do often (usually) care how many hours you spend patching "buggy, shit systems". Because programmers are expensive. Obviously. They do not care about meeting arbitrary, irrelevant standards, like extensibility for features they will never need. Because that's expensive, obviously. Meeting arbitrary unneeded goals even takes a toll on actually relevant goals, like being able to adapt software quickly. I don't understand how you think this would not be a worthwhile goal. > design it so well that it will never fail Too much black and white thinking. Most problem domains don't need "will never fail", but are ok with "fails only seldom". And meeting "will never fail" is extremely expensive, obviously. > So I guess we have to leave the good architecture to the firms where it is critical: NASA, medical devices, avionics, etc. A good architecture is one that helps towards actual goals. And that's not extreme extensibility or extreme correctness, in most cases. For a concrete example, think about a game engine. It will not meet most arbitrary goals you could make up (it will fail, sometimes, and it can't make your coffee). But still I hope you can agree that there are many really well architected game engines.