What is software development?
- a craft — knowing how to elicit requirements, design test cases, implement design patterns, etc., is a craft and a process of continuous learning. Craft for me refers to an innate sense for how to do something. Good craftspeople may not be taught, they may be born.
- a co-operative game — Cockburn’s notion that software development is not made up of good and bad decisions, but rather, like reaching the South Pole, moves that bring one closer or farther from the goal. My quibble with this concept is that if we see software development as a Wicked Problem, than the goal is poorly or not defined, and determining what gets one closer to or farther from that goal is impossible. For example, is not documenting this design process moving us closer, in that it allows more time for testing and development, or bad, in that next round, we won’t remember why we made that decision, and might have to redesign it. It would be a cooperative effort to reach a South Pole that is moving randomly each night. Cockburn addresses this by defining the goal fairly narrowly — when the software is delivered.
- lean manufacturing — Cockburn believes agile devlopment is essentially Japanese kaizen in a different form. For example, he illustrates decision dependencies (below), maps of where processes are bottlenecked.
Since becoming a grad student in software ‘engineering’ and requirements ‘engineering’, I’ve given a lot of thought to the ‘engineering discipline of software’. Shaw starts her seminal paper ‘Towards …’, implying one day we might reach the goal. I’m not convinced. I don’t have much industry experience to back me up, but it seems to me that agile techniques, in particular Cockburn’s empirically-backed statement that there is no obvious correlation between project success and process choice, suggest that the grand vision of engineering of software is misguided.
That isn’t to say that software development is all craft, either. Instead, I think what Cockburn is suggesting is that good software development is a combination of craft, softer skills like people management, and useful tools and practices, such as test-driven development, object-oriented analysis, web frameworks, etc.
In an interview, he suggests this is actually what engineering is about as well. For example, he mentions the Wright Bros. The analogy some draw between them and software is that it’s all about throwing yourself into a makeshift project and givin’ ‘er. Instead, he notes that the Wright Brothers used a wind tunnel, made copious notes on what worked and what didn’t, and applied well-understood laws of physics to their attempt.
The real challenge with the agile development approach (the four points) is the very real focus on working products. Agile-oriented projects force people, particularly managers, to produce solutions. I think one of the comforts of rigorous methodology is that it allows people to blame the process when something fails. Agile removes that security blanket and puts the responsibility for facilitating communication, identifying needs, solving problems, on the team itself, rather than the process.
Tags: agile, engineering, General, software
Entries (RSS)
Neil - I liked your post. Especially the aspect that agile approaches put the responsibility back to people (as opposed to processes). That might explain the advantage that agile approaches have over process-heavy ones. I think though that especially large, complex and/or safety critical software systems will continue to rely on process-heavy approaches. Beyond a certain point, I would assume that agile approaches are too unstructured, too unpredictable and too unorganized.
Regarding your pole analogy (which I liked very much). You might want to use the north pole in your story though: Because it (exclusively) consists of ice (as opposed to the south pole), it is there where you are actually confronted with a moving target - which is the ice masses floating around the (north!) pole.
I agree as well. Remember that we’re stuck with the ’software engineering’ label almost by accident -because the organizers of a crucial conference decades ago felt we should be striving towards the engineering ideal. Since then people have tried to match software development to engineering processes, never satisfactorily.
This is the second reccomendation I get about Cockburn’s book –I should check it out.