←back to thread

Tog's Paradox

(www.votito.com)
166 points adzicg | 5 comments | | HN request time: 0.001s | source
Show context
crazygringo ◴[] No.41914235[source]
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.

replies(6): >>41914293 #>>41914315 #>>41914328 #>>41914346 #>>41914963 #>>41915364 #
1. ChrisMarshallNY ◴[] No.41914293[source]
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).

replies(1): >>41914360 #
2. crazygringo ◴[] No.41914360[source]
> 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.

replies(1): >>41914406 #
3. ChrisMarshallNY ◴[] No.41914406[source]
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.

replies(1): >>41914446 #
4. crazygringo ◴[] No.41914446{3}[source]
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.
replies(1): >>41914495 #
5. ChrisMarshallNY ◴[] No.41914495{4}[source]
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.