HN comments: 53

Comments on actual blog post: 0

Why are people so afraid to leave replies on the author’s OC

Is this philosophising about software or does it have something to do with real life?

A major factor supporting evolution over big up-front design is the drift in system requirements over time. Even on large military like projects, apparently there's "discovery"--and the more years that pass, the more requirements change.

> There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades.

Well, there isn't a formal version of it, because the answer is not formal, it is cultural.

In enterprise software, you have an inherent tension between good software engineering culture, where you follow the Boy Scouts' principle of leaving a codebase cleaner than you found it, and SOC2 compliance requirements that expect every software change to be tracked and approved.

If every kind of clean up requires a ticket, that has to be exhaustively filled out, then wait for a prioritization meeting, then wait for the managers and the bean counters to hem and haw while they contemplate whether or not it's worth it to spend man-hours on non-functional work, then if you're lucky then decide you can spend some time on it three weeks from now and if you're unlucky they decide nope, you gotta learn to work within an imperfect system. After once or twice or trying to work By The Book, most engineers with an ounce of self-respect will decide "fuck it, clearly The System doesn't care," and those with two ounces of self-respect will look for work elsewhere.

Or, you get together with the members of your team and decide, you know what, the program managers and the bean counters, they're not reading any of the code, not doing any of the reviews, and they have no idea how any of this works anyway. So you collectively decide to treat technical debt as the internal concern that it anyway was in the first place - you take an extra half hour, an extra day, however long it takes to put in the extra cleaning or polish, and just tack it on to an existing ticket. You give a little wink and you get a little nod and you help the gears turn a little more smoothly, which is all the stakeholders actually care about anyway.

You cannot replace culture with process. All attempts to replace culture with process will fail. People are not interchangeable cogs in the machine. If you try to treat them as such, they will gum up and get stuck. Ownership and autonomy are the grease that allows the human flywheel to spin freely. That means allowing people to say, "I'm going to do this because I think that it is Right And Good For My System Which I Own", and allowing them to be responsible for the consequences. To pass SOC2, that means treating people like adults and allowing them to sometimes say, instead of "can I get this reviewed because I legit need another set of eyes to take a serious look?", to say "can I get a quick rubber-stamp on this please?"

Software cannot be built like skyscrapers because the sponsors know about the malleability of the medium and treat it like a lump of clay that by adding water can be shaped to something else.

Borrowing from mechanical/electrical etc. Limit the number of things you can build with. An example in the comments here was a gear. You make a new gear based on examples of gears that work. So whats the software equivalent of a gear? an axle, a bearing, etc.. Using OO or some ABI, you specify an object is a gear and behaves like a gear and magically you know how it does or doesnt fit together with other objects. I know this idea has been used before but im wondering if theres a well known software framework or library. We have things like the stl in cpp or built in libraries in python but im thinking of a higher level abstraction.

This missed the point that they are ignoring evolution is literally the way you build things. There is no other way. You don't know what is actually needed or what might work really. You try things and then compress later. If you can try bigger things, bigger leaps great.

> There are two main schools of thought in software development about how to build really big, complicated stuff.

> The most prevalent one, these days, is that you gradually evolve the complexity over time. You start small and keep adding to it.

> The other school is that you lay out a huge specification that would fully work through all of the complexity in advance, then build it.

I doubt many people (if they stop to think about it) actually fit into either of these two schools of thought, they're both extremist positions. It's like claiming that the US population is filled with people believing in either big government autocracy and communism or small government libertarianism and free markets. That's an absurd position to take, just as these opening paragraphs are absurd.

The most generous interpretation is that the author is setting up a strawman.

These are extremist positions. No one except a fool would think that they can design a truly large system from scratch before ever writing a piece of code, and no one but a fool thinks they can write the code for a large system without ever thinking about the design.

The reality is that it sits in between, the author figures this out by the end, fortunately, but wants something they can't have:

> There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades.

First, they at least admit that they're stumbling. That's good, groping around in the dark is not an effective way to find an answer, turn on the lights. You aren't the only one thinking about this subject.

Second, for small projects and simple projects, or rehashes of projects you've done before, the approach often doesn't matter. This only matters for large, complex, and/or novel projects.

Software development is a design process.

Again, in case this was missed: Software development is a design process.

The idea of separating design from development is foolish (BDUF). The idea of separating development from design is equally foolish (extreme take on Agile, see Ron Jeffries failing at sudoku because he tries to use a development technique, TDD, without thinking about the design).

Take the "over 3000 active systems" from paragraph 4. There is no way anyone could have designed all 3000 active systems (either as the 3k systems or in a compressed form) from scratch in a reasonable amount of time. The only reason the author can think of a better design is because they have a design, even if it's not formally documented. The existing software is the design [0] that they can draw from to come up with the better design.

But wait, the foolish BDUF people would not try to refine the system, they'd try and build a new system from scratch. Don't be a fool.

The foolish extreme Agile people would not look at the whole (or a large enough section) and think about refining it, they'd just add to it or change the existing systems.

The sensible person says, "Wait, I acn'