Past performance does not guarantee future value (Robert's Rule #4)

[Tweeted 2011-04-28]

A while ago I was in a job managing a team of software engineers. This team was a mix of people; both in terms of experience and in terms of relationship to the company (i.e. some were full-time employees and some were contractors).

Now, I tend to consider myself more detail-oriented and data driven than the average person, so it made perfect sense to me to relate software features to be developed, and all the project management related data (estimates, dependencies, etc) to my assessment of a developer's skill level and also relate the defects found to the features. In hindsight it was, perhaps, a tad more complicated than it should have been. On the positive side, it gave me quick insight into how effective my assessments were and how likely we (as a team) were to hit our projected development milestones.

One of the problems I faced was when developers took up a different task or a different language. Software development, as a discipline, is fairly straightforward. There are language skills (computer languages are made up of nouns and verbs and have direct and indirect objects just like other languages) and general concepts (like data normalization rules and network/communication protocols) that apply to all feature development, so a good developer is a good developer, right? Usually.

Usually good developers get better, but practice doesn't make perfect and a developer that handles one language with ease may not be able to make the switch to another language. Such was the case when one of the developers on my team attempted the switch from COBOL to an object-oriented language. When he popped the clutch on his paradigm shift (yeah, I started that saying back in '93) his development shuddered like an old car. In a car, if you pop the clutch, you can stomp on the accelerator and rocket off or you could try to coax it along and kill it...I believe that in theory it works the same with people.

This experience led me to conclude that "past performance does not guarantee future value" is just as true for people as for the stock market (Robert's Rule #4). This developer chose to try to coax his development along rather than immersing himself in the new technology. I don't know where his career has taken him in the years since, but it's most likely out of software engineering.