Guest post: Breaking things

Originally a comment by latsot on Overt rather than clandestine.

Breaking things can be useful, if by breaking them you are able to reassemble them in a new way that improves them

In theory, yes. In practice it hardly ever happens, with even the best will in the world.

It certainly doesn’t happen much in the software business even though we have whole swathes of theory about how to do it in software design and development practice, much of it very good.

It works like this:

1. The boss says “build me a system, don’t worry about the budget, we can sort that out later, just bring me a design”.

2. The boss sees the design, her eyes pop out on stalks at how expensive it looks and she crosses out a bunch of modules saying “combine those into one, get rid of that, make this happen by magic instead of code” etc.

3. We redo the (worse) design according to the same best practice and start building it. Then the budget changes, half the devs get moved to other projects and we are forced to cobble some hideous thing together in the same time with less money. The boss, of course, has already sold the spec to the stakeholders so if we can’t actually achieve it given the new circumstances, it’s our jobs on the line.

4. The boss realises there’s quite a lot of time and budget set aside for testing and just crosses it out saying we’ll have to test each module as we produce it and hope it all works when we put it together at the end, which it never, ever does.

So we build a shitty bit of software that doesn’t work properly or – usually – even do what anyone wanted in the first place. It is also completely unmaintainable; it is so poorly built by necessity that nobody really knows how it works and making even the smallest change is likely to break the whole thing and we probably won’t even notice until months or years down the line.

So a year later the boss finally realises she’s spending more on maintenance than she would if we just rebuilt the whole thing from scratch along the lines of our original design. She promises us untold budget to rebuild and… well, you can see where this is going, can’t you? We always end up trying to break the shitty system and put it back together in a better way, even though this is certain to be way more expensive and take much more time than rebuilding it from scratch.

This is what happens (always) in the relatively simple and well-understood world of software, which usually has at least some design principles lurking around somewhere. It is only through the dedication of developers (to solve ridiculous problems, not dedication to the firm) that any software ever works at all.

I can’t imagine how breaking things for the better can work in such things as political or legal systems, which have grown organically according to hugely divergent and regularly changing requirements, motivations and principles, sometimes across vast spans of time. Humans really don’t know how to do that. Or rather, we do, but the overheads are always unacceptably expensive so we always end up fudging it and making the outcome objectively worse and more difficult to tinker with in the future.

To be clear, I am in full agreement with your point. I’m almost always on the side of breaking things. Sometimes for the sake of it, usually with the aim of making it better. But when something isn’t built well in the first place, options are limited. The type of breaking Trump is doing is such that it will be virtually impossible to put the old system back together again, let alone build a better one, even if anyone had an idea about what a better system would be.

If I sound pessimistic it might be because Brexit is supposed to be happening in a little over a fortnight and we don’t seem to have decided anything yet. Now that is an example of breaking something to make it ‘better’ without understanding what ‘better’ means, what ‘breaking’ even means or how to go from one to the other.

2 Responses to “Guest post: Breaking things”