Certification: Natural versus Official Authority

This is a re-post of a comment I made during a discussion on Scrum certification at InfoQ. It relates some of the pressures that I see affecting the software industry. (And yes, I know it mentions Dave Thomas again. What can I say? The guy’s a legend.)

I agree, certification locks up access to a profession, often to the profession’s detriment. We have all encountered people with impressive official credentials who deliver less-than-impressive real world results.

It is the difference between natural and official authority. Fotunately, many of the brightest lights in the software community have great natural authority, authority gained by doing useful things, and by helping others. It is part of the culture.

I think the problem comes when you attempt to reconcile software’s culture with the rest of society as a whole. We are pressured into becoming an “official” profession in the vein of doctors, lawyers, and engineers. But what is wrong with aligning ourselves with professions that value experience and results, like sports, or the arts?

Dave Thomas, one of the Pragmatic Programmers, aludes to the problem of authority in his presentation titled “Herding Racehorses, Racing Sheep”. He notes how nursing faced similar challenges as software, and how they reconciled official and natural authority within their profession. Why can’t we do the same?

I am glad that the rise of agile and the certification debate are pushing these issues to the forefront. Software won’t realize its full potential until they are resolved.

Advertisement

Cost-plus Contracting Caveats

I came across an important point when reading InfoQ’s interview with Paul Oldfield, titiled Doing Agile Right (it is an excellent interview, I highly recommend reading it.)

In an earlier post I refer to cost-plus contracting as a way to align the demands of lean software contracting with the demands of a client. But Paul brings up a very important point:

I commonly come across people who do not make the distinction between manufacturing and development. They see the best practice and highly automated production line processes, and want to apply the same sort of processes. Mentioning no names, I have come across situations where payment was for time and materials. Profit was related to head count. Here, efficiency meant reduction in profit, and was only attempted when the customer could no longer accept that the head count was necessary.

This reveals the problem with cost-plus contracts, namely, how does one calculate the “plus” part, the profit? Relating profit to head-count creates the problem Paul speaks of. Linking it to time causes problems as well. (I should note that I have seen cost-plus contracting referred to as creating “gold standard” work – the best money can buy, which is what we are trying to create with lean methods. By contrast, with fixed-price work the incentive is to cut corners whenever possible.)

Lean processes, particularly Scrum, have checks that can prevent intentional waste by the contractor. Transparency plays a large role here. Idealy you get a constant time-effort tradeoff from the velocity calculation. But that assumes that the original estimate is in-line. For example, I have heard that in some professions it is common to bill 125% of your time to the project, as a matter of course. On a lean contract one could inflate the estimate by 125% and not work as quickly as possible.

Some food for thought.

Lean Software and Subway Lines

My co-worker made an interesting comment after seeing this excellent interview with Mary and Tom Poppendieck, titled “Using Lean for Competitive Advantage”. Straight to the quick: “They are right, Lean process won’t work in a contract-based environment”.

The problem is simple — customers expect you to deliver X software product, on Y date, for $Z cost, like any off-the-shelf manufactured product. However, as Mary states in the interview, software development cannot be treated this way.

What if software development was seen as a service first? Contracts would retain a team of software developers, for a fixed rate per month, for a few months. At the end of each month the team delivers working software. You can run the meter as long as you want, switch service providers at any time, or ever completely redefine the product you would like to receive. You, the customer, have complete control. Iterative development practices, such as SCRUM and Extreme Programming, make this possible.

My co-worker told me how engineering had dealt with the problem long ago by introducing “turnkey” and “cost-plus” contracts. The turnkey contract lays down a fixed cost and delivery date. A typical turnkey project would be a factory, bridge, or water treatment plant. These things have been built a thousand times before, and the challenges are well-understood.

The cost-plus contracts are the interesting part. The construction of the Shepard subway line in Toronto was done under such a contract. A team of one hundred engineers was placed at the city’s disposal, for $1 million per month, on an on-going monthly basis. The engineers would start, and later extend, a subway line under the city.

Performing any part of this project on either a fixed-cost or fixed-price basis would be crazy. Subway lines have been built before, but each one is unique. You never know what you will find while digging dozens of kilometers of tunnels under a city. You also do not know if the city will run out of money, or when the political sponsorship may change. But the subway was needed, so contracts were drawn up, financing was aquired, and the work went on until the city said “enough”.

Software projects, especially large ones, face many of the same problems and uncertainties. But customers, for whatever reasons, insist on a turnkey software solution! It is our job, as developers, to show them that there are better ways to build software. But we must also show the customer how ‘software engineering as a service’ is a better way to finance projects.

Engineers must be able to calculate per-month contract rates in order to write cost-plus contracts. And they must be able to show their clients when metered contract work is necessary. Lean software development could probably learn something by studying how engineering cost-plus contracts are drawn up and pitched.