This can't be a new idea, but it is new to me, and I doubt that very many people have paid enough attention to the problems of software to have thought it through well enough.
Estimation. How long will it take? When can I have it? Why isn't it done yet? Perennial issues. I know — writing software isn't the same as building a bridge. Writing software isn't building anything. Writing software is imagining something.
The building part is hitting a key or two and generating another copy of the runnable software, but the writing of it is not equivalent to construction. The writing of software is equivalent to one part of the planning and design process. Equivalent to one of the last stages of that, but still not the same as piling bricks on top of each other.
And yet, especially with what is called "agile" software development, or more often these days, what has been congealed into "Agile", the process depends on starting by asking naive users of an existing system, or equally naive future users of a system not yet built, what such system should do: Getting "user stories".
Does anyone suppose that this might be a way to build a nuclear submarine? A power grid? Would anyone ask a few random commuters how a new highway bridge should be built? No? Then why ask "users" what a software system should be like?
It seems to me that any business that needs a software system should put muscle into the process, should get serious, should actually commit. Experts should come in on the first day and really seriously hash out in detail what the laws are, what the business requires, how things are done now and how things need to be done once the new software is in place, and skip the story nonsense.
User stories be damned. Get serious already.
Sure, lots of big material projects go sideways all the time, but no one starts building a bridge across a river and ends up with a barrel factory. Because people are committed to getting it right. Things get sloppy when people do, not because things are inherently sloppy and completely unpredictable. Pay attention, work closely together, and don't let anything happen without it receiving close and continual scrutiny.
Run this sort of system a couple of times and you have a factory that can generate solid, clean, working software, and if you need estimates, then good ones ought to come along as an inevitable part of the process.
Can't be that hard, not if anyone really cares enough to treat development as if if mattered.
Have anything worth adding? Then try sosayseff@gmail.com
Me? Haven't quit thinking yet.
Etc...
so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals