

Over-engineering considered useful - martius
http://www.isbullsh.it/2012/05/Over-engineering/

======
alttab
Failure is the fastest way to success. I wrote over 500,000 lines of game code
before I ever graduated high school and only 1 project ever saw the light of
day. Learning from all of my mistakes back then made getting the degree in
college much easier.

Also, completely rewriting things is a major skill for a professional.
Churning out great code, and doing it fast and with few bugs is worth a lot in
the industry

~~~
Drbble
Completely rewriting things is one of the worst decisions an intermediate
engineer makes. That's what killed Netscape.

Applying learning to a new project, now that is something different.

~~~
spacemanaki
> Completely rewriting things is one of the worst decisions an intermediate
> engineer makes. That's what killed Netscape.

This is commonly trotted out to discourage re-writes, but how does that square
with another piece of common advice: "build one to throw away" ?

I'm genuinely curious, and I'm not trying to pick on you specifically. There
are just many different situations where one or the other makes sense, so I
don't think it's so cut and dried.

~~~
rwallace
It's not cut and dried, but a good guideline is this:

If you've written a program, but it _doesn't work yet,_ and you've realized
you made major architectural mistakes or whatever, feel free to rewrite from
scratch.

If you've written a program and it's been in real use for a while, solving
real problems for a lot of happy users, that means it embodies a lot of
knowledge that will be difficult to re-create from scratch; in that case,
think very carefully before embarking on a rewrite, and look hard for a way
forward that will preserve that knowledge.

------
delinka
When you're talking about physical devices and structures, I like
"over"-engineering: e.g. those extra cables keep my elevator in the shaft when
one fails. In the case of the physical world, I think we can define over-
engineering as engineering to much more than the minimum required. Another
example is two-lane bridges: the sign says "16 T" but obviously, two vehicles
could be on the bridge at once, headed in opposite directions, and it has to
hold up for decades. Exactly what specifications are used to build the bridge,
I have no idea. But it's obvious to me that it's "over-engineered."

I don't think we know enough about solving problems with software to detect
over- and under-engineering before ... I don't know. Before we _need_ to?
Before users complain that it doesn't work? Before MegaSoftCorp spends a few
million too much?

~~~
icegreentea
In 'real' engineering, every engineering calculation has a safety factor
attached to it. You figure out how much you need, and then you multiply it by
the chosen safety factor to get what you need. The choice of safety factor
varies. In some cases, it may be regulated/required. In other cases it is
based on the engineer's judgement. And of course, it will vary from field to
field. In aerospace, safety factors are typically much lower than in civil
engineering, since weight is a much greater concern.

Which brings back to why we have a safety factor at all. The only reason why
we have it is because of uncertainty. The real why we have safety factor at
all is because we don't know enough.

------
fghh45sdfhr3
The terms "over-engineering" is so ill defined as to be mostly useless.

I have a strong personal opinion of when things become over-engineered, but
that means little.

I've worked for smaller companies, which tend to under-engineer due to time
restraints.

And I've worked for large corporations with such overkill process that it is
amazing anything gets shipped ever. And yet it does, it takes almost forever,
and costs far more than it should, but it does eventually ship.

Discussing "over-engineering" may be fine for general interest communities.
But I think on HN we should aim higher. I'd love to have a rigorous discussion
on how we can identify designs as either over or under engineered.

~~~
nicalsilva
Sure! This post is like an invitation to discuss the subject, right?

"over-engineering" was not the point anyway. The title is a lie. The point
was: dont be afraid of making mistakes (Over-engineering and the likes) when
you can afford to, so you can learn from them and aim at high quality
discussions on HN.

~~~
srbravo1
well said

------
gatlin
To me programming is both engineering and something akin to literary
composition. You want your _design_ to be engineered well - perhaps "over"
engineered for redundancy and reliability - but you end up actually building
it with a formal language. This brings me to a wonderful quote:

"A scrupulous writer, in every sentence that he writes, will ask himself at
least four questions, thus: 1. What am I trying to say? 2. What words will
express it? 3. What image or idiom will make it clearer? 4. Is this image
fresh enough to have an effect?"

\- George Orwell

The first two apply to composition in a formal language. Over-engineer the
structure of the thing but be as merciless as Hemingway when actually
composing your thoughts and sentences. Eschew excessive lines and actual
tokens. Those are the byproducts of the rushed and/or cluttered mind (which
commercial projects may necessitate ;)

------
AdrianRossouw
I agree with the premise, that over-engineering is bad.. but the only way to
know it when you see it is to have done it before in the past.

i know i wouldnt have been as completely allergic to complexity as I am, had
it not been for some very important life lessons on the subject.

------
Akram
Cant agree more. Especially startups should be very careful not to get trapped
in an infinite loop of engineering. In my previous failed attempt we did just
that. Built feature after feature but nothing could ever see the light of the
day until it became an overkill.

------
snorkel
Crazy exploratory programming is the best way to learn and grow your skill set
... but please don't do this in a team project where other developers have to
grapple with your insane abstractions that lead nowhere and mental meanderings
... keep it to yourself.

