Agile vs. open
The two liveliest software development models are open source and agile.
In some ways, these models are orthogonal. Open source is primarily a licensing model. Open source projects can use agile practices — short cycles, test-first, pairing — or they can have long cycles with compartmentalized development. Agile is a set of development methods which can be used with open or proprietary licences.
In another way, they seem to conflict. Classic open source projects are put together by programmers seeking to “scratch their own itch”. Agile projects are oriented around meeting the needs of a customer.
Agile projects bring the customer on the team; make the customer responsible for setting priorities; develop shared understanding of requirements with conversations remembered as stories. The best way to make sure customers get what they want is to give them software soon, and let them respond to real stuff.
By contrast traditional development processes formalize customer requirements in long, structured requirements documents, which get delivered in big lumps of software. The goal of management during the development cycle is to fend off changing customer requests.
The extreme open source position contends that software developers won’t ever develop for other people unless they have to. This can be explained as Asperger’s — a physiological lack of empathy. Or it can be explained as a Romantic/Bohemian view of artistry — true artists paint and poets write for themselves and their muse, and their small group of starving but virtuously anti-bourgeois friends.
The extremes are wrong. Introversion isn’t “better”, open source doesn’t have to be solipsistic, and development for money doesn’t have to be corrupt.
Introversion isn’t better I think that the Romantic view of open source software is as fallacious in software as it is in art. Artists have always had relationships with audiences — Homer was a storyteller, Shakespeare was a crowd-pleaser. There are always “artists’ artists” — those whose work is difficult and revered by the cogniscenti. Software made for customers isn’t guaranteed to be bad any more than art made for audiences.
Open source can have empathy The goodness of the Mozilla project disproves the notion that open source projects make software that only ubergeeks love. The Mozilla crew are building lovely software — see the Scott Collins interview over at Ars Technica.
Commercial development can have integrity Agile development practices are intended to work around structural temptations for commercial projects to be build on lies. First, salespeople lie — they promise things to customers without listening or wanting to believe developers about how long things take. Then, developers lie. Out of eagerness to please or fear, they tell management and sales what they want to hear. Reality intrudes eventually. Customers get mad. Really mad customers sue. Agile planning is based on continual delivery and continual conversation, to avoid the built-in temptations for lies and self-deception.
Money communicates priorities When people are developing for others, money focuses attention. When customers want things that don’t yet exist, dollars vote. Willingness to pay focuses the mind of the customer on what’s important to them, and the developer on what’s important to the customer.
What do you think?