Uncharted Waters

Oct 28 2019   8:30AM GMT

On Productivity

Matt Heusser Matt Heusser Profile: Matt Heusser

Tags:
Development
productivity
Programming
Teams

Matt's productivity bookshelfLast time I discussed the secret stories about computer science from the end of my childhood, and one that had gone missing. The piece, the Parable of two programmers, appears in Wicked Problems, Righteous Solutions, published in 1991. It is the single best short story on programming productivity I have ever read. The book had long vanished to the winds of time, but a few years ago I bought a copy.

Then, two days after that last post, the copy jumped out at me. I opened up the book, did not find it in the index, and instead looked a page at a time. There, on page 167, was the parable of two programmers. A little help from a search engine and I found the piece, by Neil Rickett, still exists on the internet in a few places. Tim Mensch repeats the story entirely, then adds a section at the end where he basically claims to be charles, one of the ultra-productive programmers that I suggest you either become or else become close friends with and deeply appreciate.

However, that is not the productivity secret I took from the story.

Leaving me free to tell it to you.

Short form story

Two programmers are working on identical programs at two different companies. The first, Johnny, is self-taught and has no formal process. He spends the first third of the project looking out the window and occasionally making notes. The second, Robert, is a recent Masters in Software Engineering graduate. He does it “right”, creating a specification. Realizing the problem is harder than it first appears, he convinces his company to hire a small team of four people to implement. Robert supervises them and implements code review, hires a temp to do testing, and so on. Nine months later, a bit past the original schedule, Robert’s team delivers the program that is essentially what the customer thought they wanted nine months previous. Looking at the code, Robert’s director realizes the problem really was more complex than originally planned, and offers him a promotion to senior manager. The tester becomes a permanent employee.

Johnny, on the other hand, works with the customer to deliver the project on time. Looking at the code, his manager realizes the problem really was far simpler than they initially thought. Plus there was all that staring out the window time. At the annual review, Johnny’s manager gives him a “meets expectations”, and a raise slightly smaller than inflation.

DeGrace and Stahl’s note the hero of the story is the hacker, Johnny. My take away is not nearly as optimistic.

Productivity Noteswicked productivity book

Robert’s team spent seven times as much on that software as Johnny’s company did. The software was not as good. The companies are otherwise equal – the money will mean less profit this year. Yet Robert’s manager is happier, by far.

You could take this as some of advice to manage expectations, that perception is reality. I sure hope you don’t take it that way. Take that advice too far and you don’t bother to work, or add value at all. I am certainly not encouraging that. I will suggest that perception matters. If you fail to manage that, your own good work may go un-noticed, un-appreciated, even un-used.

Just as important, notice that there is no real way to measure productivity here. Fifteen years ago, Dr. Kaner wrote “Software Engineering Metrics: What do they measure and how do we know?” If you haven’t heard of it, the article is worth a read … but the conclusion of his work can be summed up in that story of the two programmers.

Conclusion

Accurate measures of productivity are more likely to appear as anecdotes, like the tale of two programmers, then as lines of code. They can, of course, be a lie. There are also areas of expertise. An expert on Jenkins who is not otherwise very good might do something in a day that takes Charles a month. And still Charles can be more productive on, well, everything else.

Still, when I see numbers on a chart, I want to dig in to what is really going on. I want to understand what the functionality does and how long it took, and talk about why. The interesting part is the discussion, not the number.

So walk around. Listen. Pay attention. Dig into the details.

The best yardstick for productivity may just be an engaged software leader.

Perhaps next time I add my own personal story to the list.

 

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: