Comment by davidkhess | Hacker News Reader

Comment by davidkhess | Hacker News Reader

Parent Full thread

The only part of the agile approach I like is iterative delivery.

First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value.

Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality.

If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality.

Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.

> First, I believe software blueprints should be put together by people with 15 to 30 years of expertise.

Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on.

> Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value.

Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects.

And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects?

> If you are in a project where there are large numbers of unknowns about the functionality of the project

... that would be vast majority of them.

> I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality.

Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile.

> scope reduction should be used until the unknowns have been reduced to a reasonable risk level.

That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.

> Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on.

How many years of expertise do you think architects of large buildings probably have? Engineers of critical bridges and other public infrastructure? One thing we need to do is stop aging out our best talent.

> Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects.

> And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects?

Absolutely. I have a 100% success rate using these techniques with over 20 under my belt. Granted, I'm mainly a solo operator but I've used it for larger projects too on occasion.

> Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile.

The difference is time frame and phasing. Consider deciding to enlarge a kitchen in the middle of building a custom house. Now compare that to an addition to an existing home. They are very different situations.

> That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.

The difference again is the time frame and the phasing. Messing with the scope/design every week I think is an anti-pattern and a contributor to project failure.

Reply on news.ycombinator.com