[SystemSafety] Putting Agile into a longer perspective

Steve Tockey steve.tockey at construx.com
Mon Oct 21 22:58:56 CEST 2019


Robert P. Schaefer wrote:


“this sounds very much like the economics of conducting experiments and not at all like the economics of engineering.”

But it IS engineering economics. Or, at least it SHOULD be. It’s called “Decision making under risk and uncertainty”. A well-known strategy is “buying down risk”: invest a little to learn a lot.

Just the same, “don’t invest a lot to learn a little”.

And, for what it’s worth, students in recognized engineering disciplines are required to take experimental science classes for exactly the reason of having them understand empirical reasoning.



“Out of curiosity, has anyone ever proposed a science of software development?”

Yes, of course. It’s called “Computer Science”. Look at the curriculum at any reputable university that offers CS degrees:

*) Algorithms and complexity
*) Sets, relations, and functions
*) Finite automata theory
*) Inductive and deductive reasoning
*) Numerical precision, accuracy, and error
*) Measurement theory
*) …





From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of "Robert P. Schaefer" <rps at mit.edu<mailto:rps at mit.edu>>
Date: Monday, October 21, 2019 at 12:28 PM
To: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Putting Agile into a longer perspective

this sounds very much like the economics of conducting experiments and not at all like the economics of engineering.

what’s worse, there appears to be very little “science" in the conduction of these experiments - its more on the order of heuristics.

but that is just me, i guess.

Out of curiosity, has anyone ever proposed a science of software development?

and if so, would the sciency part be similar to the sciency part in political science?


On Oct 21, 2019, at 3:17 PM, Steve Tockey <steve.tockey at construx.com<mailto:steve.tockey at construx.com>> wrote:


I believe it was Fred Brooks who said in 1975, about the OS/360 project in 1965,

“Build one to throw away”

Unfortunately, building just the first one is really expensive. Who ever really throws it away and builds it again?

What agile zealots seem to blissfully ignore is how necessarily high-overhead agile (or, any iterative process) is. Each iteration REQUIRES:
*) making assumptions about what may or may not turn out to be true in future iterations
*) high probability of re-work due to past assumptions turning out to be incorrect
*) regression testing to make sure modifications didn’t break something that was working before

More iterations necessarily means more overhead.


As well, consider Steve Mellor’s great quote:

“The number of times it took you to get it right is a measure of just how badly you did it the first time”


Now, on the one hand, it can be the case that the time-value of early learning and / or early delivery outweighs the necessary overhead of iterations. In this case, it truly does make sense to be agile (iterative).

On the other hand, iterating on code is what makes it so very expensive. The “recognized” engineering disciplines learned long, long ago,

“It’s a lot damn cheaper to iterate on models"

Depending on the nature of the model, it can be so cheap that you really can afford to build many more than one to throw away.


So there you have it:

1) iterate when and only when the value of early learning / delivery sufficiently outweighs the necessary overhead of iterating
2) iterate as much as possible on inexpensive models that can be thrown away cheaply, don’t iterate on code if you can at all avoid it


— steve



From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Olwen Morgan <olwen at phaedsys.com<mailto:olwen at phaedsys.com>>
Date: Monday, October 21, 2019 at 11:29 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: [SystemSafety] Putting Agile into a longer perspective



Oh, dear. Why did this one crop up at a time when I felt like having a real rant at it ... ?

There are some very good things about Agile. The continuous integration devops processes that support it are extremely useful in critical systems development. But the demagogues of Agile are missing a critical matter in software technology. Agile practices ideally require means for developing software that are so powerful and efficient that if you've got the software wrong, it's still affordable to throw it away and start again. (Not an original thought - AFAI recall, Tony Hoare said something to similar effect back in the early 1980s.)

Agile will work only when we've made rigorous software development so streamlined that we can afford to throw incorrect systems away several times during the course of a project and yet still deliver within reasonable time and cost constraints.

Who is working to make such rigorous development cheap and efficient? ... I don't know of anyone who I think actually understands the essence of the problems enough to get going on a credible project. I've got some ideas on how one might make a start, but every time I speak to people about them, they appear to think I'm bonkers - and for all I know, maybe they're right.


plus ca change,

Olwen



_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20191021/7f9a9b09/attachment-0001.html>


More information about the systemsafety mailing list