[Tutor] Pair 'o dimes wuz: Volunteer teacher

[Leam Hall]

On 7/24/22 06:47, Alan Gauld via Tutor wrote:
> On 24/07/2022 01:53, Leam Hall wrote:

>> spend a lot of resources on failed projects and no-longer-useful designs.
> 
> This is a flat out myth! The vast majority of lage scale projects
> succeed, very few are cancelled or go badly wrong (they are often
> over budget and over time, but thats only measuring against the
> initial budgets and timescales). It's just that when they do fail they
> attract a lot of attention because the cost a lot of money!
> If a $10-50k 4-man project goes belly up nobody notices. But when
> a 4 year, 1000 man, project costing $100 million goes belly up it is
> very noticeable. 

If the are over budget or over time, then the project and the design failed. You can still pour resources into something, and stretch the calendar, but I've worked for some of those Fortune 500 companies. "On time and within budget" is the extreme rarity.

> But the fact is that our modern world is run by large scale software
> projects successfully delivered by the fortune 500 companies. We just
> don't think about it and take it for granted every time we board
> a train or plane, turn on the electricity or water, collect our
> wages, etc.

Our modern world is run by large scale, complex software that is buggy and often unsupportable. When weekly or monthly patch updates may or may not work, but they are always needed, then you have another sort of failure.

(Taking this out of context, but in partial agreement)
> But you can't build 4000 man-year projects using
> agile - it's been tried and invariably winds up moving to more
> traditional methods. Usually after a lot of wasted time and money.

Yes and no. I wouldn't want to build an aircraft carrier totally with Agile methodology. However, aircraft carriers are mostly known technology, and in theory design shouldn't have too many surprises. Some software is like that; you can have a three tier application (web, middleware, db) in a myriad of variations, but the tiers are pretty standard. If you can nail down how things connect then you can keep the internals fluid and responsive.

I've been on those million dollar projects that bust the budget and the schedule, and I've seem some really good project management skills displayed during high visibility projects. Waterfall, or Big Design Up Front, in theory can work when every component is well known by all responsible teams. That is seldom, if ever, the case. That's a lot of what fueled Agile, I would guess. Re-reading Uncle Bob's history on it now.

Does tradition, and sticking to what the founding fathers meant, have a place? Again, yes and no. Both can have value, depending on the context. Neither is intrinsically evil, but neither are they universally useful. Follow tradition and stick to the intent when it helps you build better software. Find something when it causes you to fail.

Leam

-- 
Automation Engineer        (reuel.net/resume)
Scribe: The Domici War     (domiciwar.net)
General Ne'er-do-well      (github.com/LeamHall)