Post #104,848
6/4/03 1:37:44 PM
|
Most Methodologies have their basis in fantasy
RUP is among them. The scrum guys figured this out with the help of process researchers at DuPont Chemical's Advanced Research Facility
Why do the defined processes advocated by SEI CMM not measurably deliver? We posed this question to scientists at DuPont Chemical's Advanced Research Facility, where research into biochemical processes is applied to process automation.
The scientists inspected the systems development process. They concluded that many of the processes, rather than being repeatable, defined, and predictable, were unpredictable and unrepeatable. With that, the scientists explained the difference between predictable (defined) and unpredictable (empirical).
If a process can be fully defined, with all things known about it so that it can be designed and run repeatably with predictable results , it is known as a defined process, and it can be subjected to automation. If all things about a process aren't fully known-only what generally happens when you mix these inputs and what to measure and control to get the desired output-these are called empirical processes.
A defined process is predictable; it performs the same every time. An empirical process requires close watching and control, with frequent intervention. It is chaotic and unrepeatable, requiring constant measurement and control through intelligent monitoring.
Models of empirical processes are derived by categorizing observed inputs and outputs and defining the controls that cause them to occur within prescribed bounds. Empirical process modeling involves constructing a process model strictly from experimentally obtained input/output data, with no recourse to any laws concerning the fundamental nature and properties of the system. No a priori knowledge about the process is necessary; a process is treated like a black box.
The scientists further stated, "We are most amazed that your industry treats treat these ill-formed processes as defined, and performs them without controls despite their irregular nature. If chemical processes that we don't understand completely were handled in the same way, we would get very unpredictable results."
We confirmed that we also get unpredictable results, such as undelivered systems, delivered systems that are unusable by the customer, and the systems development process going on interminably without adequate output generated.
Regarding the systems development process, the scientists concluded that they are mostly empirical, because :
* Applicable first principles are not present
* The process is only beginning to be understood
* The process is complex
* The process is changing and unpredictable
From [link|http://www.controlchaos.com/ap.htm|http://www.controlchaos.com/ap.htm]
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
|
Post #104,850
6/4/03 1:46:47 PM
|
Let's see if I can summarize
Another quote from your link: Writing software is a creative process, like painting or writing or architecture. When trying to create something that has never existed, it is difficult to reproduce the method used the last time it was done. Is that about it? ===
Implicitly condoning stupidity since 2001.
|
Post #104,855
6/4/03 2:44:00 PM
|
Basically, yeah
I've got a degree in engineering.
When designing a structure, an engineer can calcuate expected stresses and design parameters, then go to a handbook of properties of materials and look up some values for *well characterized properties* of different materials before selecting one for the job.
A few software components are equally well characterized (Oracle for example). But the rest of it is like trying to do engineering with alien metal and no materials analysis lab. Basically you build something with it, try to use it, watch it break, analyze where and how it broke, and add/remove/change something to cope with the factors that made it break. This is empirical. Unlike engineering which is fairly well defined (you can look up the stress properties of a given alloy and know what will break it - this is defined), empirical stuff is inherently unpredictable (but not unmanageable).
The madness is trying to treat an inherently empirical process as defined. Management doesn't like empiricism. No surprise since a company's stock price is heavily tied to whether a company performs as predicted and empirical processes are filled with unpredictabilities.
The software industry is thoroughly delusional in many respects. This is one.
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
|
Post #104,889
6/4/03 7:38:28 PM
|
Which brings us to the essential tension in SW today:
The madness is trying to treat an inherently empirical process as defined. Management doesn't like empiricism. Which is a shame, because most good programmers I know are "good" precisely because they are "good at" empirical systems, not at defined systems; the only defined systems they work well with are those they have themselves designed.
Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
|
Post #104,908
6/4/03 9:58:48 PM
|
Re: Basically, yeah
That was very much how rockets were developed. You said - "well, I have to make this basically controlled explosion that goes in a determinate direction right in the middle of a wad of fuel pipes, steering arrangements, and coolant and hydraulic functions. So you made something and watched it destroy itself, over and over again.
-drl
|
Post #104,920
6/4/03 11:29:17 PM
|
Ummm...
That was how the Americans did it you mean.
The Russians developed this little branch of mathematics called "control theory" allowing them to predict before they built the rocket whether it would be a stable system (hence probably won't fall apart) or an unstable system (hence likely to explode) without building it.
Or so claimed the engineer turned mathematician who taught the advanced ODE course I took...
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #105,051
6/5/03 6:07:42 PM
|
There's nothing wrong with Methodology...
provided you're willing to pay for price for it.
The shuttle's computer are generated by a Level 5 CMM group. They're certified (and have worked) without problem for a long time now. (There's a wonderful article about them out there somewhere).
What's in the article (between the lines) is the cost for going CMM. The shuttle's code is the most costly per line than any other code (probably by an order of magnitude). Time to market? (ie: how fast they can recognize and push a fix out the door?...don't even ask. (It's that bad.) And don't ask the cost of upgrading the systems to newer computers. (Forget about using that new processor from AMD).
CMM works VERY well with well defined system and minimal changes where speed is not of the essence.
Why businesses seem to ignore these costs is beyond me.
|
