Lhotka's Labrynth
Are Your Incentives Working?
Make sure developers don't sacrifice quality for the sake of finishing.
A colleague of mine likes to repeats this mantra: "You get what you incent for." In my first job, there were financial incentives for getting our tasks done faster than the original schedule. So it comes as no surprise that the developers focused narrowly on the tasks assigned and scrambled to get each one done in the least amount of time necessary, so as to pad our paychecks. After a few months, the program was discontinued because the resulting quality decline was unsustainable. Far too often we accomplished one task at the expense of creating bugs in other parts of the application -- bugs we didn't find because we were so focused on getting paid our bonuses.
Along the same lines, I spent many years working in IT for a manufacturing company. One consistent rule in manufacturing is that anything you measure improves by 10 percent automatically. We certainly found this to be true. On several occasions, I watched as a new quality or productivity metric was devised and the results were posted daily or weekly; in each case, the quality or productivity measured improved rapidly.
There's a lot of truth to these concepts, and it's worth considering what they mean to your development project. What are your incentives based on? What are you measured on? How do these incentives affect how you approach designing and coding the projects you work on?
In my experience, most development projects have no real incentives for developers. A schedule is imposed on the developer, and meeting that schedule is no different than not meeting it in terms of positive benefit. The same is true with quality. Meeting a quality goal (in the rare case one is set at all) is no different than not meeting it in terms of incentives.
On the flip side, if you miss your schedule or your quality goal, you might find the project sponsor yelling at people in meetings, and you might find yourself working some late nights and weekends. Perhaps this is motivation through pain or something, but few people find these techniques effective. Most consultants are paid by the hour, so typically only salaried staff worry much about working some extra hours on a project. In any case, these are not the kinds of incentives that are likely to motivate developers to create better, more robust software.
If there are rarely any incentives, what measurements are applied? Usually, the measurement is time and money. Did the project finish close to the scheduled completion date (typically adjusted as scope changes within the project)? Did the project cost about what was anticipated (again adjusted as scope changes)?
If you look at those measurements, they're not unlike those used in my first job. Developers are encouraged to work fast, to avoid "wasting time on extras" like documentation, testing, or anything that slows the process of coding toward completion.
One way to address this issue is to force certain practices, such as testing, into the process. This brute force approach is favored by a lot of agile and test-driven techniques, and it can work. It works because metrics are placed on the quality aspects of work, not just on meeting milestones on time. And if you can convince the project sponsor that it's worth the time and money required to build all the associated tests (and in the long run it certainly is!), then this is a workable solution. Unfortunately, in my experience bidding on work as a consultant, the first thing a client wants to cut to "save cost" is the testing.
And so it is that I always come back to "you get what you incent for." If a project offers no incentives to its developers, they draw their incentives from external factors: how to spend more time with the kids, or how to pad the paycheck, or how to get that bonus for extra hours billed.
We all have incentives to do something, and I think it's a mistake for project sponsors and managers not to offer incentives to their teams if they meet the project's goals of schedule, budget, and quality. So ask yourself: Are your incentives working as intended?
About the Author
Rockford Lhotka is the author of several books, including the Expert VB and C# 2005 Business Objects books and related CSLA .NET framework. He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the Principal Technology Evangelist for Magenic, a Microsoft Gold Certified Partner.