I used to think when I finally got ‘good’ this wouldn’t happen anymore, but nope, I think it’s just the way it goes. Not that things don’t get _better_. I also keep trying more ambitious things, maybe the problem is my ambition continually outpaces my skill. :)

[If this were an xkcd comic, my mouseover would be “My room’s in the pagoda, if you can hit the window with a pebble i’ll throw down a rope ladder”]

2 Responses to yep, pretty much

When I think about this, I usually end up on incentives. For most of the software development world, there aren’t sufficient incentives to prevent the situation pictured. In fact, I would imagine that some portion of the mess is caused by the incentives. I presume that people who write software where lives hang in the balance have sufficient incentive to avoid this, or to at least have additional systems or processes to mitigate the “harm” of the mess.

Hmm, I don’t feel like my problem is just insufficient motivation/incentive. I’m pretty darn motivated to make awesome software, and I know a bunch of other people who are too but still end up in panel two.

But perhaps software in domains where stability is of the highest priority sacrifice other things instead — cost, features, etc. It’s true that neither stability nor elegance of design is my only goal, or even neccessarily always the highest one. And of course ‘stability’ and ‘elegance of design’ are not the same thing. I’m guessing software in those domains (where lives hang in the balance, or having no bugs or crashes is otherwise of the utmost importance) — changes very very infrequently. In software (unlike _most_ houses), that kind of ‘messy’ design has a two-way relationship with how often/much the software is added too — it’s both more likely to result when the software ‘grows’ a lot, and is more of a _problem_ when the software grows a lot. I bet if you’re writing software where lives are in the balance, it’s pretty strict ‘waterfall’, and changes to requirements/features are not tolerated at all, and new ‘versions’ are released in infrequently. And of course, there are still sometimes failures there, like the famous case of the bad UI that led to radiation overdose in scanning machines. Or 3 mile island.

Although I may be conflating things — there is software where lives in the balance. Such software sometimes ‘fails’, causing catastrophes that can be blamed on the software — does that neccesarily mean that it was caused by messy _architecture_? I don’t think so. Software could have a messy architecture but be safe, or vice versa, I think.

But man, Devon, you really want to think ‘the market’ is the answer to everything, eh?

I don’t think money is my primary motivation, or the motivation of most developers who create really awesome software. If someone told me, okay, the absolute most important thing here is to create an elegant design — sacrifice everything else to do that. Include only the most essential features. Make the UI not as nice as it could be, just barely good enough. If absolutely neccesary, even let the project go over deadlines/budget. Just make sure the architecture is as elegant as possible. — I’m pretty sure I could do that. I doubt it would be the right thing to do, with just about any software.

I think it’s less about incentives, and more about balances between various priorities, and that complex software is just hard. expressed in aphorisms like “fast, cheap, good — pick two”. (if they just had the right incentives, could they make it fast, cheap, and good? Um.) Except there are more than three factors, there various aspects within ‘good’.