Deathray Research

“Experience alone, without theory, teaches management nothing about what to do to improve quality and competitive position, nor how to do it.” W. Edwards Deming

For some people, software engineering is a solved problem and Agile is the solution. If a project is small enough, management enlightened enough, and customers sufficiently supportive or powerless  - in other words, if it’s an easy project - Agile is the way to go. 

But it’s not enough: 

• It leaves open the question of how to continue improving. How do you outperform the other “Agilistas” and build a firm-specific advantage in engineering? 
• As an individual, you compete globally with engineers also using Agile who have a significant cost advantage. How will you feed your kids ten years from now?
• Software projects differ. Complex projects differ from simple ones. Web software differs from medical device firmware. When goals are different, any technique must support some better than others. To customize the process you need to combine a solid theory with intense study of your own situation.
• Agile methods focus heavily on coding and testing and say less about things like requirements and operations. It’s impossible to optimize an entire process while focusing on one part. 
• Agile is likely not the final advance in development methodology. Open Source, for example, is a far more radical rethinking of software production, and one with important lessons for developers. 

In manufacturing, the techniques that make up Just-in-Time (to which Agile is often compared) are less important than the realization that every aspect of the process is a control to be manipulated, coupled with a “relentless pursuit of understanding and improvement.” 

Which brings to mind another lesson from Just-in-Time, the distinction between “pragmatic” JIT - characterized by a patient and exhaustive focus “on the concrete details of the production process” - and the “quasi-mystical hyperbole” of “romantic JIT.”  Much of the writing about Agile (“People over Processes”) tends towards the romantic, making it simultaneously more appealing and less useful.  

None of this makes Agile ‘wrong’; It’s not, but too many people use it as a cook book and when they need to improvise they’re stuck.  They need to learn to cook; not just follow recipes. 

Is there a ‘universal theory of big software’?  I think the pieces exist, rooted in economics, systems dynamics and other disciplines.  They’re just waiting for someone to pull them all together. 

That someone is not me.

I’m reminded of William James’s remarks on his own ground-breaking text Principles of Psychology. He called it ”a loathsome, distended, tumefied, bloated, dropsical mass, testifying to but two facts: 1st, that there is no such thing as a science of psychology, and 2nd, that WJ is an incapable.” 

In the posts that follow, I hope to produce something worthy of similar praise.