
Ask HN: Why is writing maintainable code hard? - shipen
Recently I have took interest in watching documentaries for ship building, general constructions and mega projects; and it occurred to me that much of these efforts require much better precision and coordination than coding.<p>The tolerance for failures in these projects are much lower than most coding projects, yet it would seem to an untrained set of eye that alot of these projects are more successful than many coding projects in terms of maintainability and final output.<p>Hearing many horror stories about legacy code bases, and currently experiencing one myself, I would believe that the methodology used in managing these constructions is much superior than those managing code bases.<p>I was wondering if anyone has any insights on my observations and have any suggestions on managing techniques that would improve the action in building and maintaining large code bases.
======
twunde
A couple thoughts on this. 1) Most projects aren't expecting to be around in
20 years much less 10 and are built accordingly. 5 year old codebases are old
and typically are replaced. 2) The ease of change is both the biggest strength
and the biggest weakness of coding projects. If you're building a ship, nobody
is asking for changes to the plan on a weekly basis. This ability to change
rapidly has been emphasized by agile and lean startup methodologies. 3) Few
projects know exactly what they're going to look like, what features will be
used. Construction projects will have blueprints that are followed. 4) You're
probably assuming that these projects are better managed. I'm not sure that's
the case. Many houses will have problems where things weren't constructed
properly such as bad wiring.

Coding projects do have techniques that can be followed including automated
testing, and writing specs

~~~
meric
Yes and I note we have built buildings and ships for thousands of years, and
software only for the past 150 years.

------
PaulHoule
(1) Shipyards build the same ship over and over again (2) There are no
licensing, guilds, labor unions, professional associations, professional
societies, etc. covering most areas in the field. (3) Although the bulk of all
software effort goes into maintenance, new software is rarely built with
maintenance in mind. (4) Different skills in different heads; financial
companies sometimes send out I.T. architects to take the Series 7 so they
understand enough about the domain to talk w/ domain experts (5) A tricky
balancing act between "necessary complexity" (complexity required to manage
complexity in the task) vs "surplus complexity" (often something that makes
you want to punch the wall, but often something you're deeply attached to.)

------
w4tson
Also, imagine if they delivered the ship 2 years later and the client said
"its all about on-land ships these days, we really need it to move on land
too, oh and can we make it with sails, sails are cool. But we don't want to
compromise on speed"

------
carlmungz
I would also say the ease at which existing code can be changed (even if the
end result is worse) doesn't help. It's much harder for a zealous engineer to
overhaul the design of a bridge than it is for a new programmer to refactor a
legacy codebase.

------
LarryMade2
Here is a visual illustration - [https://i.ytimg.com/vi/L5RzYV-
ICu4/maxresdefault.jpg](https://i.ytimg.com/vi/L5RzYV-ICu4/maxresdefault.jpg)

You start out with something really nice and functional, soon you have some
issue that needs a patch now, then another, then you need to write additional
modules but no time to re-code to adapt... But don't worry, everything just
works great!

If you take time now and again to maintain code you are good, if you take time
to get code in place properly you are good (but probably sill making more
minor messes..)

------
muzani
A lot of legacy code just works. Building something new or updating means
introducing new bugs, even if aggressive testing catches it.

New tech isn't always better. I tried to convert one site from PHP to RoR
once. At the time, it seemed like a great idea, now it seems pointless. Still,
is it really necessary to change a site from C to Java?

Another issue is that it can be very expensive. Google and Facebook is always
cutting edge tech because their survival depends on it. Same with Boeing or
Rolls Royce. But ask a bank if they can spend a few millions upgrading from C
to Java and they'll be very unhappy.

------
gt565k
Unrealistic deliverable deadlines, poor management, scope creep, poor team
organization / hierarchy, ignoring technical debt, inexperienced developers
all contribute to poor code quality.

Take your pick.

------
imauld
I imagine it has to do with the fact that most software applications won't
kill all their users if they crash.

Additionally the fields of mechanical engineering and architecture have been
around far longer than software engineering, hundreds and thousands of year
respectively compared to what 70?

