Find the complete talk, audio/video by Alistair Cockburn with slides on the InfoQ site. I am spending a lot of time on Agile Software Development techniques, and this talk presents a number of important concepts, so I am posting my notes here to help others looking for good materials on Agile software engineering.
Software Development Definition
Alistair defines software engineering as:
- People inventing, deciding, communicating
- Solving a problem they don’t understand which keeps changing.
- Creating a Solution they don’t understand which keeps changing.
- Expressing Ideas in Languages they don’t understand which keeps changing.
- to an interpreter unforgiving of error
- Making Decisions with limited resources, and every decision has economic consequences.
Cost of Distance
Distance is expensive.
- Say that two people sitting and working on the same screen, asking each other questions every 20 minutes is a cost of zero. Thus a 12 person team working this way would be the base “cost”.
- If people are in the next office with a wall in between, they have to stand up and walk next door, a 12 person team will incur an additional cost of $100K
- If people are located on separate floors of a building, a 12 person team will incur an additional cost of $300K, but more importantly, people will stop asking the questions which might be more damaging.
Learning in Three Phases
- Shu – learning a technique, starting by copying something.
- Ha – collecting techniques.
- Ri – invent, blend techniques.
Comparing Manufacturing and Software (Design)
- Software development can look like manufacturing if the unit of inventory is “Unvalidated Decisions”. Each line of code is a decision. All of the specifications are decisions. High level decisions are broken into lower level decisions, and programmers code the decisions ultimately into the product. Software development then is a factory to “process decisions”.
- Manufacturers hate feedback and rework. Doing something again is evil and wasteful, but this is not the case in collaborative design. Reworking is not a problem.
Want to aim for continuous flow. Avoid big waves of code. Small batch size. Nano-incremental development. If you are sending 1000 lines of code to test — too big! Instead, send daily integration to test.
Theory of constraints. Watch your bottlenecks.
Design is Knowledge Acquisition
Trying to learn about a domain, and trying to learn about a solution. When do you know most about the problem? The day after you deliver.
- Waterfall: there is a lot of typing, but the learning happens at the moment of integration. Learning everything at the end is bad. Waterfall is a late-learning strategy.
- Agile: growth of knowledge can be faster than cost because of early, rapid integration.
- Highest Business Value First – a sort of hybrid where you alternated between exploratory learning and then implementation.
- Trim the Tail – can decide toward end when to ship and whether to delay, because risk is low.