Tog's Paradox

Not really sure what makes this a "paradox"?

Seems like a lot of words to say that, when you deliver the features users want, then they will continue to want more features. (And all these features keep making users more productive/efficient, so it's a good thing.)

And, of course, more features means more software complexity.

But I'm struggling to see a paradox here, or even what's supposed to be the novel observation.

What makes it a "paradox," is the classic Waterfall model that most companies (even ones that say they are "agile") use for development.

In Waterfall, the design and requirements are "one and done." They are not supposed to be revisited and iterated.

Once we have gone past "thresholds," we are not supposed to go back, without many staff meetings and begging to Higher Ups.

I have found that I need to make my entire product lifecycle iterable. I need to have a "done" state, so that I can get something out, and that needs to be extremely high Quality, but I also design my projects to be re-entered, and re-implemented, with the expectation that I'll be rapidly jumping back in, and making fairly significant changes (not just bug fixing).

Yeah its really not a paradox. There's nothing contradictory in the observation. Increased efficiency making it possible to introduce more complex tasks is not inexplicable at all.

I think the paradox comes from the assumption that one of the goals of a software product is to simplify a human task. Where the paradox comes into play is that it actually increases the complexity of that human task.

I could be wrong!

it's paradox in a sense that reducing complexity actually ends up increasing complexity; Tognazzini originally proposed it as a complaint against Tesler's Law ("Conservation of complexity"). Tesler observed that complexity stays the same when people try to reduce it. Tognazzini suggested that the complexity doesn't stay the same, but actually increases.

> In Waterfall, the design and requirements are "one and done." They are not supposed to be revisited and iterated.

The article doesn't seem to be about waterfall though? But even if it were, I don't see what's novel here. In waterfall, the design and requirements are "one and done" for version 1.0. But then you plan a version 2.0 in response to the new features desired, and then 3.0, and so forth. In any case, the article doesn't even mention waterfall or agile, so I don't think it's about that.

The article isn't really about any particular model. It's about product development, in general.

> ...But then you plan a version...

Yeah, but these are painful. I know of which I speak, as I worked for decades in Waterfall companies.

Rapid iteration at High Quality is really difficult, but it's also the only way that I've found, that delivers truly useful software (the products that I write). It's a great deal more difficult to do this with hardware, though.

I worked for hardware companies, for most of my career, and suffered hardware development methodologies forced upon software. It was painful.

Since working on my own, I have developed what I call "Evolutionary Design" techniques, and they seem to be working, but I also work at a much more humble scale, than I used to.

I can understand the concept of conservation of complexity -- that you can reduce steps ("complexity") for the user by automating those steps in the software and making the software more complex.

But then you don't need to build more features. The "conservation of complexity" obviously assumes that the feature set is static. Once you allow the feature set to grow, obviously complexity will increase.

So I still not only don't see the paradox, I continue to just see common sense. I don't see what's supposed to be new here.

Sure, I totally agree with you. That's why waterfall gets a bad name. It just seems like waterfall vs. agile is a totally separate topic from the article.

But the prevalence of Waterfall is the elephant in the room, that interferes with rapid iteration, which is what the article is about.

We can ignore it, if we like, but it's still there, making big giant ploppers on the coffee table.

Technically the complexity is done by somebody to reduce the complexity for somebody. If it would be 1:1 it would stay the same, but since one solution can be copied to many the complexity overall reduces. But the reduced complexity gets filled again. So reducing complexity increases complexity. That's the paradox.

Add I see it, the paradox is that while users might say that they want the software to be "simpler" to use, what they actually want is more complex software where each particular action is simpler.

For us developers it may not look as a paradox, since we're so used to constantly adding levels of abstraction, but to me it does seem like a paradox on the UX front.

It's a "veridical paradox". A statement that seems impossible to a naive mindm

Those famous "paradoxes" that are actually true are only paradoxes on the context of other widely believed ideas. And, of course, those other ideas are false.

This one is a paradox on the context that the way to create software is to make a complete specification first, then implement it.

> But the reduced complexity gets filled again. So reducing complexity increases complexity. That's the paradox.

But it doesn't increase if you just don't add new features. Nobody is forcing you too.

Reducing complexity doesn't add complexity. It simply doesn't. It's the adding further features that does. Which you have a choice over.

Software is build upon and ideas are spread, when something exists if will be extended. In this context it will get more complex, that’s how I understand it at least.

I guess at some extend it’s in the human nature to never be sated.