In software development, it is very hard to establish the effects of individual contributions and good teamwork is key to the project. Most individual compensation schemes, according to the presentation, absorb vast amounts of management time and resources and leave nobody happy, but team compensation strategies are not easy to implement. Mary presented results from HP’s experiments during the beginning of the nineties, when HP allowed 13 local organisations to experiment with team-incentive plans. All programs were discontinued by the 4th year, due to constant changes to the plans which were needed to distribute available money among the teams and a wide dissatisfaction with the plans by employees.
Use profit sharing schemes instead of bonuses to tie people to the organisation goals.
keep in mind the norm of reciprocity — if people feel that they are being treated generously, they will reciprocate it with increased discretionary effort.
Through agile development, I’ve been able to deliver working software time and time again. I’ve been exposed to all different aspects of the business. I’ve learn what I like and don’t like to do. I’ve learn what pieces of business I’m interested in and the pieces I don’t care much for. I’ve developed some really good working relationships. I’ve tackled some hard problems. I’ve learned to respond and adapt to the change and turmoil of a startup.
Most importantly, I still feel I’m growing as a developer. I honestly believe the best thing a developer can do in their career is to always be learning. Everything else will follow.
I am also a strong proponent of agile software development. Information Technology projects have a poor success rate. The best method, I have found, to provide better software solutions is agile development (and I find a grounding in management improvement techniques is useful – customer focus, process improvement, systems thinking, understanding variation, data driven management…). My experience is with custom application development (rather than developing Commercial Off The Shelf software – COTS) for which I think agile is a great fit.
The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or productivity.
In years since the original study, the general finding that “There are order-of-magnitude differences among programmers” has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).
I think these orders of magnitude are not present in between people in many jobs. And I think people’s ability to correctly access who are orders of magnitude better is often faulty. But my experience leads me to believe the difference between exceptional software developers and average (not even below average) is very high. High enough that large increases in pay (say tripling would be sensible). Also accommodating their desires is sensible: freedom from dealing with pointy haired bosses and eliminating other such de-motivators.
While salespeople seen as successful can often be rewarded very well, exceptional software developers rarely are. Most managers don’t seem to be able to grasp that software development is a rare field where such orders of magnitude differences are somewhat common (not one in a million, maybe one in a thousand for a random guess). There are other fields where this is true but most for most fields I do not think this is the case.
In this 90-minute talk from the Agile2007 conference, Lean software thought leader Mary Poppendieck reviewed 20th century management theories, including Toyota and Deming, and went on to talk about “the matrix problem”, alignment, waste cutting, planning and standards. She closed by addressing the role of measurement: “cash flow thinking” over “balance sheet thinking”.
The wonderful cartoon in this link illustrates the all too common despair in work. Software programmers are more likely to really enjoy what they do. There are many reasons for this not the least of which is that they have a fair amount of control over their careers. If they don’t like what they are asked to do, the tools they are asked to work with… they will (more than others) leave for another job. Some managers get frustrated that such people are not willing to put up with the normal bother everyone else seems willing to accept (programmers are often “unreasonable”). But I see an occupation that is more focused on joy in work than most. And creating joy in work is what managers should be worrying about – not getting troublemakers to fall into line.
Harmony and balance make you feel good. American Rubyists frequently take up all the points of Ruby’s power, expressiveness, and efficiency, but they don’t seem to register the point that Ruby was designed to make you feel good. Even Rubyists who want to explain why Ruby makes them feel good often fail to mention that it was expressly designed for that exact purpose.
Don’t program in Ruby because you want power or efficiency. Don’t program in Ruby because you think you “should”, either. Program in Ruby because you like it. And if you don’t like it, don’t program in it.
The example above is the tale of two Web 2.0 startups scaling to 20 systems during their first three months. The first team starts writing software and installing systems as they go, waiting to deal with the “ops stuff” until they have an “ops person”. The second team dedicates someone to infrastructure for the first few weeks and ramps up from there. They won’t need to hire an “ops person” for a long time and can focus on building great technology.
In my experience it takes about 80 hours to bootstrap a startup. This generally means installing and configuring an automated infrastructure management system (puppet), version control system (subversion), continuous build and test (frequently cruisecontrol.rb), software deployment (capistrano), monitoring (currently evaluating Hyperic, Zenoss, and Groundwork). Once this is done the “install time” is reduced to nearly zero and requires no specialized knowledge. This is the first ingredient in “Operations Secret Sauce”.
This is a nice short article discussing startup IT operations. On that topic it is interesting. It is also a good example of how a bit of up front planning can help any organizations. Make plans on realistic options – which often means not expecting everything to be perfect. Expect to have to make do with fewer resources than you would like but are what you will likely have… At work, I use subversion, Ruby on Rails (and practice continuous build and test – I’ll take a look at cruisecontrol.rb) and we are setting up Capistrano. I’ll let our system administrator know about puppet (it looks useful) and take a look at the monitoring options (we have something in place now, I forget the name).