Dan Abramov on how he once overnight refactored a piece of WET code written by a colleague, but then got called out for doing so:
My boss invited me for a one-on-one chat where they politely asked me to revert my change. I was aghast. The old code was a mess, and mine was clean!
I begrudginly complied, but it took me years to see they were right.
There’s a fine balance to be found between code that works for the team and code that is clever/abstract/clean. Sometimes it’s better to write cheap code, as that’s not only cheaper to read, but also cheaper to maintain, cheaper to throw away, etc. — Abstractions are good, up to a certain extent.
On Twitter, Dan also said this about // @TODO comments:
TODO doesn’t mean you actually intend to do something. It’s a marker for the next person that the logic was left unfinished and they shouldn’t be surprised by missing corner cases or strange code structure.
On July 8, 2015 the New York Stock Exchange went down due to a software glitch. Over at Medium, Zeynep Tufekci went into detail on how it comes that software sucks.
Software sucks for many reasons, all of which go deep, are entangled, and expensive to fix.
LAYERS AND LEGACIES: A lot of software is now old enough to be multi-layered. Airline reservation systems are particularly glitchy since they’ve been around a while. I wouldn’t be surprised if there is some mainframe code from the 1960s still running part of that beast.
TECHNICAL DEBT: A lot of new code is written very very fast […] Software engineers do what they can, as fast as they can. Essentially, there is a lot of equivalent of “duct-tape” in the code, holding things together. If done right, that code will eventually be fixed, commented and ported to systems built for the right scale — before there is a crisis. How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there’s the temptation for more duct tape. And so on.