[Tutor] Pair 'o dimes wuz: Volunteer teacher

[Alan Gauld]

On 26/07/2022 01:10, Leam Hall wrote:

>> 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). 

> If the are over budget or over time, then the project and the design failed.

Not at all. If the requirements changed (and they invariably do) then
extra cost and time will be required. Thats true of all large projects
not just software. Large building projects like the English Channel
Tunnel went over budget and took longer than expected. It is impossible
to accurately estimate cost and timescales based on an initial
requirement spec. That is understood and accepted by anyone working on
large projects. It's true of small projects as well but the margin of
error is much smaller and theefore typically absorbed by contingecy.
But accountants don't like "contingencies" of $10 million!

But if you dream big you must expect to spend big too.

A project only fails if it doesn't deliver the benefits required in a
cost effective manner. Judging a multi-year project based on time/cost
estimates given before any work is started is foolishness.
Most large projects do deliver eventually.

> Our modern world is run by large scale, complex software |
> that is buggy and often unsupportable. 

That's not my experience. especially in safety-critical systems
like air-traffic control, power-station control systems etc. Sure there
will be bugs, even formal methods won't find all of them. But our world
would simply not function if the software was that bad.

> When weekly or monthly patch updates may or may not work,

That's bad. Most large mission critical projects I've worked on work on
6-monthly (occasionally quarterly) releases rigorously tested and that
rarely go wrong.

> Yes and no. I wouldn't want to build an aircraft carrier totally 
> with Agile methodology. 

That's the point. I've used Agile on large projects at the component
level. Each component team runs an Agile shop. But the overall project
is controlled with more traditional techniques and the overall
architecture is designed up front (albeit subject to change, see above).

> However, aircraft carriers are mostly known technology, 

Mostly, but each generation has a lot of cutting edge new stuff too!

> a three tier application

That's what design patterns are for.

> 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... Waterfall, or Big Design Up Front, in theory can work 
> when every component is well known by all responsible teams. 

Which, as you point out is the case of 80% of the code in a large
system. (Also in most small systems too for that matter!) The
trick is to identify the 20% that doesn't fit (but that can be a
difficult trick up front!) and apply more flexible approaches
such as prototyping and Agile in those areas.

And then risk manage them like crazy!

> Does tradition, and sticking to what the founding fathers meant, have a place? 

Only to provide context. Unlike much of modern software engineering the
early programmers were driven by research and had the time to study the
best approaches based on data not anecdote. They couldn't afford to do
anything else given the tools available. Our modern tools are so
powerful we can afford to waste cycles trying things and if it doesn't
work roll back and try again. But the hard-won lessons of the past
should not be forgotten because they mostly remain valid.

But at the same time we must maximize the benefits of the
modern computing power too. Otherwise we'd still all be
drawing flowcharts and using teletypes!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos