Lefkowitz has spent a long time trying to encourage large organizations to adopt open source techniques. His current employer uses the Microsoft solutions framework. This has a process model and a team model, and it's difficult even to get everyone in the organization to sign up to the models. Before the company used that they used another methodology with four phases, and Kent Beck's "Extreme Programming" uses six phases. All these methodologies are different, but subtly similar.
How do we define a methodology that everyone can use? R0ml believes we need to drive the development of the process broadly based in the open source world. He referred us to Quintillian's five-step rhetorical framework, which might have been lifted directly from the Microsoft framework had it not been written in the first century AD.
| Rhetoric | MSF |
| inventio | Envision |
| dispositio | Plan |
| elocutio | Build |
| memoria | Stabilize |
| pronuntiato | Deploy |
Other techniques or methodologies can also be mapped on to the rhetorical framework.
The architect Alexander observed that the events that take place in a place are primary in determining its fitness for purpose. Juggling uses two different notatiopositional notation, but some jugglers use "causal" notation, which focuses on throwing a club when it must be thrown to maintain stability. 70% of the MVS operating system is dedicated to exception handling, which is why they are so stable.
R0ml suggests starting with "release early/release often" as a starting point. Next, you use it (which you will notice is completely ignored by traditional methodologies). Bug and exceptions reports and patch submissions are then followed by triage and integration. The difference here is we don't have "requirements". There is no development, there is only maintenance; it's just that some maintenance is more radical that others (laughter).
XP puts some stress on the customer by requiring them to make decisions, write user stories, write functional test specifications, and so on. But the most powerful input from the customers is their complaints when the software doesn't do what they want. (More laughter).
This was an amusing talk, which anyone who has seen this speaker in action before would expect, but I'm not sure there were many pieces of practical advice for open source developers. I got the impression from a somewhat abrupt finish that Lefkowitz didn't have enough time to fully expound his thesis. A shame, since the last talk I saw was informative as well as amusing.
For some reason a number of posts were stuck in the blog as drafts. This one is from July last year.
No comments:
Post a Comment