My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resources working in a different country.
I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is not to have one.
As the quote goes: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
You can, and should, have specifications for the next ~two weeks of changes that you want to do. These should be verifiable at a user-facing level. But after that you iterate. Trying to specify further in advance or at more detail than what's user-visible is a recipe for disaster.
We completely agree here - are you saying you've never encountered the "we're agile, no need for specs" mindset?
I've found the "we're "agile" but going to have a huge up-front spec" mindset far far more damaging.
And yet we flew to the moon. And have airplanes, and and and.
A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever. Example: People still write their own date conversions (and fuck it up).
We do, but not by designing from scratch. We achieved those things by incrementally extending existing designs and verifying that the newer, more complex designs had the desired properties.
> A lot of agile is just an excuse for software "engineering" being in the throw shit at the wall and see what sticks stage of evolution. Construction went through the same, software has freemasons now. But no engineering whatsoever.
The constraints that apply to software are very different from those that apply to construction. What if "throw shit at the wall and see what sticks" really is a better way of making software than "engineering"?
> Example: People still write their own date conversions (and fuck it up).
Indeed they do. Do you find this is more common in projects that specify and design up front or in projects that don't?
What if it isn't.
Those large scale projects were not done in a Waterfall fashion, they were done iteratively with models/simulations/prototypes produced along the way.
models/simulations/prototypes != iteratively
"Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product."
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
It depends.
With certain projects, the overriding risk is that you're building something that nobody wants. In this case, Agile makes a lot of sense, and specifications are a waste of time until you've validated customer demand.
For other projects, you're very confident that demand exists for the product you're building, and specifications start to make a lot of sense.
Big caveat though - you can get this assessment very very wrong. "Demand" can be a very open-ended concept (e.g. in the entertainment industry), but that doesn't necessarily translate to user satisfaction. No Man's Sky, for example, probably should have been put in front of players a lot earlier. That means building to a looser spec in shorter cycles with more iteration (more "Agile", for want of a better term).
This is why product managers are so important - they need to make this judgment. It's a difficult balancing act to juggle "minimum features and user testing", "grand product vision" and "efficient and manageable development cycles".
Backlog items in most processes called agile are specs, and most variations include an activity of assuring that they meet whatever quality standards are in place prior to being eligible for development.
It's more common for places claiming to be agile to not have any integrated spec for what has been built than to not have specs of each to-be-built unit, AFAICT.
I've had some horrific experiences where multiple developers worked on the same features (without specs) while stepping on each others toes.
Technical talent is a the-odds-are-good-but-the-goods-are-odd kind of deal - at least outside Silly Valley in the developing world. You can hire a huge sum-total-IQ but you can't hire people who can work independently and collaborate.