I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/

Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

▲

jiggawatts 3 days ago | parent | next [-]

My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”.

I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.

	▲	zelphirkalt 3 days ago \| parent \| next [-]
		That's fine ... only have to size your projects accordingly!
	▲	BurningFrog 3 days ago \| parent \| prev [-]
		That actually sounds brilliant!

▲

mattacular 3 days ago | parent | prev | next [-]

Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)

▲

wpietri 3 days ago | parent | next [-]

I think this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required.

But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.

Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.

▲

QuadrupleA 3 days ago | parent | prev | next [-]

You absolutely can remove unnecessary complexity. If your app makes an http request for every result row in a search, you'll simplify by getting them all in one shot.

Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.

▲

mattacular 2 days ago | parent [-]

I'm not talking about unnecessary (nor incidental) complexity. That is a whole other can of worms. I am talking about the complexity required given what you need to a system to spec. If choices are made to introduce unnecessary complexity (eg. "resume driven development" or whatever you want to call the proclivity to chase new tech) - that is a different problem. Sometimes it can be eliminated through practical considerations. Sometimes organization politics and other entrenched forces prevent it.

	▲	2 days ago \| parent [-]
		[deleted]

▲

einpoklum 2 days ago | parent | prev | next [-]

If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.

Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.

▲

2 days ago | parent | prev [-]

[deleted]

▲

zelphirkalt 3 days ago | parent | prev | next [-]

I think most people don't really claim, that complexity is gone when properly abstracted, but claim that you don't have to deal with it every single time. That's the purpose of abstracting something.

Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.

▲

JuniperMesos 3 days ago | parent | prev | next [-]

> I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/

I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.

	▲	otterley 3 days ago \| parent [-]
		I don't follow. Following the robustness principle doesn't necessarily introduce novelty. Perhaps a bit more complexity, but just how much depends on how clever you try to be. What did you mean?

▲

leoc 2 days ago | parent | prev [-]

Like most of the things Spolsky says in that article it’s pretty dubious. Following it to its logical conclusion, presumably on-call debugging work be even easier if the software had been handwritten in assembler.