Ask HN: Why is writing maintainable code hard? | Hacker News Reader

Ask HN: Why is writing maintainable code hard?

9 pointsshipen9 comments

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.

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.

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.

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.

View on HN

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

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

(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.)

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"

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.

Here is a visual illustration - 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..)

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.

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.

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?

Reply on news.ycombinator.com