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?

9 thoughts on “Agile vs. open”

  2. Very nice summary of the virtures of agile and open development processes. Now, how about a development environment that merges these approaches? Like where customers tell stories about problems and then lay out rewards for fixing them? Key question: What processes do you design to support the competitive and collaborative efforts to win the payouts?

  3. Good ideas. The LazyWeb collects suggestions, but doesn’t yet have a good way to build community or financial support for solutions.
    I suspect the competitive and collaborative dynamics work similarly to traditional business. We have:
    a) projects in the same domain, which compete for users and developers. When a user picks a project, they have some degree of lockin in terms of invested time and integrated system.
    b) custom consulting, which may be selected using an interview process, and then involves work done on contract. In this case, open source would govern the IP term of the contract.
    There are also bounty systems, which have potential benefits and ethical problems (work on spec). More discussion welcome.

  4. Thanks for the summary, especially of agile programming, which was just a buzzword to me. For others new to the topic, can you point us at a one-pager that fleshes out some of your other terminology (“short cycles, test-first, pairing”)? Or just tell me to RTFG (read the fine Google).
    Now, my naive response.
    In art, I think it would be a crying shame if we tossed out either the “Romantic/Bohemian solipsistic” model or the crowd-pleasing one. They’re extremes on a continuum all points of which can be useful (actually it’s got more dimensions than that but I’ll save that thought). Most artists engage to some degree in both and in my opinion that is as it should be.
    In software, I don’t think of good open-source development as solipsistic or of good commercial development as being slavishly client-driven. I know open source mostly by the fruits of its labors, but from the outside it looks like an intensely social process. And a lack of empathy would preclude some crucial aspects of modern software, like usability. The browser I’m typing this into was clearly not written by autistics. As for commercial software development, as in any field involving expertise there are times when the experts have to ask, do we give the clients what they really want or what they think they want? I count on my doctor not to let me OD on painkillers and on my architect to have a better sense of design than I do. Ideally there’s a give and take and a mutual educational process between expert and client, and it sounds like agile programming is a good technique for formalizing that process.
    As a business practice, agile programming sounds terrifying. How do you price out an open-ended process without requiring one side or the other to assume all the risk? Writing contracts around giant predetermined specifications has never been particularly efficient, but it does have advantages in terms of meeting a budget and ensuring you won’t get ripped off. You touch on this in your last comment but I don’t have a clear picture of what you’re saying. Agile programming wouldn’t have gotten this far without some creative payment models; what are they?

Leave a Reply

Your email address will not be published. Required fields are marked *