Tagprogrammer’s productivity

The Cost of Waiting for Feedback in Software Development

[In the series ‘Explain this to me like I’m a manager’]

Let’s imagine you are paid to write emails.

The company you work for has a policy that all public emails from an executive should be written by someone with a clear head and proper training. That someone is you.

It works like this:

  1. You receive an in-person briefing from the executive of what the email is about.
  2. You go back to your office to work on the email. In case a question arises, you phone the executive and usually get an answer right away.
  3. When finished, you present your email and edit it together until you’re both satisfied with the result.

The whole process takes about half an hour up to several hours.
This seems OK. It might even be kind of fun, right?

Now, imagine a different way of working

The only difference is that you’re not sure when you’ll get feedback or approval. It might be right away, or it might take several weeks.

Since you don’t know how long it’ll take, you start working on the next task. Instead of having 1 email “in progress,” you might have 20, 30 or a whole lot more.

This the exact same job, with the same input, but it seems much more cumbersome and a lot less fun, or not?

Well, unfortunately, this is the way most developers are working

In this example, we’re assuming there is no middleman (PM, analyst…) through whom all communication passes, introducing his or her own ideas, obfuscating the message in the process.

As a developer, I have often found it very frustrating when it takes ages to get feedback or answers.

You start working on something. You get stuck, you need feedback. Because you don’t know when you’ll get answers, you put the task on hold and start working on the next one.

But wait, the client has the exact same frustration!

Yes, I’ve been there: for several years, I worked on the other side, steering contractors/freelancers to develop custom software for our organization.

It is just as annoying to give extensive feedback to a developer, only to get additional questions 2 weeks later. These questions are usually ones that could have easily been answered if asked right away, but 2 weeks later, I can hardly remember what it was all about!

Surely, there are better ways to waste my time!

What is the engineer’s solution?

Let’s use a tool to manage all this “work in progress”, with statuses, flags, due dates, source integration, custom fields, assigned persons, reports, milestones and all that jazz.

This is an often unnecessary over-complication that is regarded as standard practice.

“That’s how it’s done!”

There are indeed situations that demand this way of working.

But, most of the software projects out there are actually quite straightforward and don’t benefit from these “solutions.”

The root cause is still there: it takes too long to receive feedback. As humans, we can’t temporarily store our built-up understanding—our “grasp”—somewhere until we need it again.

So, what’s the alternative?

We are all busy and we can’t just drop what we’re working on whenever someone demands our attention. But what if we could?

What if we could work on 2-3 tasks at the same time?
What if we didn’t need tools (except for a basic to-do list) to manage the progress of all our tasks?
What if we could work intensely with the client on a few tasks from beginning to end? And not start a new task until these were actually completely finished?

Why am I asking these questions? Because it would save time, money and frustration!

This is one of the core elements of several task/project management frameworks that suggest focusing on a limited number of tasks during so-called “sprints,” or that impose a limit on the “work in progress” (a WIP limit).

Often advocated. Seldom practiced.

And really, no one is asking you to drop everything at every question; just don’t let things slide forever.

Do we really waste that much time waiting for feedback?

There was a study, conducted at Palm in California, the makers of the first PDAs. This study measured how much longer it takes a developer to fix a bug detected 3 weeks later instead of on the same day.

Now, how much longer do you think it takes?

About twenty-four times as much, no matter if the task is big or small.

Did you also fall off your chair? My initial guess was 5-10 times, which should be enough to inspire anyone to give this some additional thought.

But waiting endlessly for feedback isn’t the only cause of WIP explosion!

It’s also:

  • The delay between analysis and development
  • The delay between development and testing (if you use testers)
  • The delay between a developer reading the tester’s feedback and acting upon it
  • Waiting for approval or a sign-off on something

Now, how do we fix this?

Well, it’s not that hard… to write about! 🙂

Here are my suggestions, which should work no matter what role you’re in:

  • Try to get everyone on board. Send them the link to this article. Or send them this excerpt from The Scrum Book; the author is just a bit more known than me, so it might work better! 😉
  • Lead by example: give feedback and answer questions on the same day or at least within 24 hours.
  • Explicitly state that you try to give feedback asap. Actively request the same from everyone you work with, including clients and managers. Follow up if necessary. A lot of people let things slide until they notice you’re consistently following up.

And, if your role allows:

  • Try to get everyone (necessary/needed) working on roughly the same task(s) at the same time.
  • Try to limit the number of tasks and the “work in progress.” Impose a WIP limit.
  • Cut the number of in-between-persons. They often serve no real purpose, except to consolidate or translate information. Developers often communicate too technically. I still make this mistake myself. But I also believe you can learn to communicate on a more non-tech human level. Listen to what is really being said, and try to respond at the same level using the same words.

I think it’s always better to have direct communication lines because it improves the possibility of learning from each other.

But I’m a developer. I can’t just demand my client’s attention!

You’re not demanding immediate attention; you’re asking not to wait for ages to get a reply.

I know this is not the standard way of working for a lot of developers: being proactive instead of reactive, reaching out instead of tackling that next user story or bug. I don’t mean to be condescending. I speak from my own practice, from the mistakes I’ve made, from experiences with failed as well as successful projects.

This might be one step (of many) to becoming a “10x engineer” and to show that you’re on top of things and care about the project.

Remember, all those non-tech people you’re working with really don’t know much about software development.

There’s nothing wrong with steering and educating them on how to optimize the process and save time and money. Who could be against that? (Unless, of course, your time is billed by the hour 😉

… And what if you get feedback from multiple sources, contradicting each other, even contradicting your own opinion?

Tackling “Design by Committee” is another story. Sign up here and stay informed.


Your Developers Aren’t Bricklayers, They’re Writers

This article got voted Best “Everything Else” Article of May 2015 on CodeProject.
It trended on Reddit, where it generated an at times heated discussion.


If you have ten programmers, the best one is probably at least five times better compared to the worst one. No shit.

Define better: he works faster, produces less bugs and writes more readable, logical and maintainable code.

Programmers aren’t bricklayers or carpenters, but they are often treated as such. (not that there’s something wrong with these occupations)
“Why would I get a senior when I can get two juniors for the same price?”
“This feature takes three months for one programmer? Let’s just put two more on it so we can have it in a month.”

And why is that? Because there’s no decent, fool-proof way to measure the productivity of a programmer, I guess? Whatever can’t be measured, gets ignored. I’ve seen it too many times. [Tweet]

Also: would you rather have two juniors deliver your baby, fix your car, perform a lumbar puncture, or would you rather have one senior? Despite popular belief, the act of producing code is not a commodity. [Tweet]

The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

Robert Glass, Facts and Fallacies of Software Engineering

If you really want to compare, then I’d say programmers are more like writers.

Some writers can produce a page turner that goes on to sell millions, while another might produce something that is so boring it extinguishes the fire it’s thrown in!
Yet, they both produced a book and thus they’re both writers, and you wouldn’t know the difference unless you’d really start reading the book.

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

Fred Brooks, The Mythical Man-Month

Let me give you an actual (yes, IRL) example

(Names have been changed to protect the innocent.)
The Company (no, not the CIA, just some software company) needs to implement a new module in their flag product. Mr. Lousy is free at the moment; great, let him start right away!

After four months of tinkering, Mr. Lousy is finally finished. The QA team finds loads of bugs and inconsistencies that need to be reproduced and reported back to Mr. Lousy. He then spends two weeks fixing those bugs and finally delivers a new version! Those are damn annoying bugs and Mr. Lousy often thinks about them while he stares into the distance.
This test/fix cycle is repeated two or three times.

The users have been promised this new module. Sales will be able to sign with some new customers that have been waiting for this module. There’s considerable pressure to just get it out there and it gets incorporated in the next release. Hurray! Champagne for everyone!

Unfortunately, the new module is still rather buggy. Customers are excellent at finding previously undetected bugs. So they contact support. The support team tries to find out what’s going wrong, whether the customer’s confused about the feature, whether they’re confused themselves, or whether it’s just a bug and can be reproduced. Yada, yada, yada. They decide to file a bug report. Unfortunately, Mr. Lousy is wreaking havoc—oh, I mean he is working on another project at this time, and he can’t just drop everything to fix them pestering bugs.

(And we haven’t even talked about whether the code is maintainable, logical and documented. Because sooner or later someone else will need to make enhancements, add features, etc.)

But, uh-oh…there are some bugs that Mr. Lousy can’t seem to fix. Also, new bugs turn up and no one is sure if they are indeed new, or just weren’t discovered before. Support gets pestered. Sales are getting annoyed, because those new customers find the module is too unreliable for day-to-day work and want to cancel their contract!

And, finally, the boss asks Mr. Rockstar Developer to take a look at the code.

Mr. Rockstar isn’t really able to make heads or tails of it and sees lots of senseless constructions. He advises to rewrite the code, thinking it’ll take about a month. He gets to work and hands over the finished module in just a few days longer than his original estimate (he’s Mr. Rockstar, not Mr. Perfect). Besides some minor bugs that are quickly detected by the QA team, everything works as expected. The QA team starts to worry: if they’d all be like him, they’d be out of a job. Mr. Lousy thinks that Mr. Rockstar is an arrogant twit, but this isn’t really relevant.

The revised module gets released. Everybody is happy because it finally works. Hurray!
Congrats! Rejoice! Champagne again!

By this time, it’s usually forgotten that Mr. Rockstar managed to do in about one month what Mr. Lousy couldn’t in 7-8 months.

The huge difference between these two developers only surfaced here because they performed the exact same task.

By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.

Phil Haack, 10 Developers For The Price Of One

Now, what is the worst that could happen here?

Mr. Rockstar eventually notices that he’s considerably more productive than Mr. Lousy. And, don’t be fooled, he doesn’t need to get the same task to find out. This is his job; he’s damn good at it and he easily recognizes bad code written by a bad programmer. Still, he’s pretty sure (or absolutely sure) that Mr. Lousy is earning more or less the same amount of pay. He gets disgruntled and/or he quits. And you’ve just lost a considerable amount of production power for your development team.

Even if he doesn’t quit, how do you think he’ll feel when a release/project is running late and the whole team is ‘punished’ with overtime? This is the inevitable waiting to happen.

If you’re really out of luck, he’ll be replaced by another Mr. Lousy.

So, why does this go unnoticed so often?

Because it’s easier to ignore this issue than to fix it—at least up to a certain point, and also because no one likes to rat on colleagues and be the cause of someone losing his job; because Mr. Lousy has three kids and just bought a new house; and, most importantly, because it’s very hard to measure a developer’s productivity, unless you’re really able to compare them both doing the same task as in the above story.

Are you a developer? Do you agree? Please let me know in the comments. Almost all non-tech people think ‘one developer day’ is an exact measurement. [Tweet]

Now, I’ve been thinking a lot about this: measuring a developer’s productivity. I’ve often been jealous of salesmen because their remuneration is based on their accomplishments. I’ve got some ideas (still ripening) on how to separate the wheat from the chaff. I’ve also been thinking about and will be posting about how to identify, attract and retain the Mr. Rockstar developers.

Sign up here to get notified about these and future posts via email.

Related articles:
10 Developers For The Price Of One
What Makes Bad Programmers Different?
What Makes Great Programmers Different?
Discussion on StackExchange: A good programmer can be as 10X times more productive than a mediocre one

Who am I and why am I telling you this

I’ve worked as a professional developer (that is, getting paid for it during a daytime job) for over 10 years. I made my first commercial product (a game) in 1989. Although this didn’t make me rich, it still felt great (I was 16 at the time). A couple of years later, I sold the idea of one of my games, and it eventually got released on the Nintendo Gameboy (and other formats) by Bandai! I can tell you from experience that it’s very satisfying to see something you thought up (including the name) actually being sold in a shop.

In 2008, I took a non-tech job at a very technology-driven company. I wanted to learn about running a business in general, about the sales process,… everything non-tech that happens in business. Well, my tech chops probably got me hired and are still very useful, but they are no longer an essential part of the job.

I don’t program for a living anymore (or rather: at the moment), but often tinker with various new technologies in after-hours projects. To me, it’s the same as reading a good book—exciting and relaxing at the same time.

In my current role, I often encounter people who express certain misconceptions or who lack basic knowledge of the development process. In their role (often CxO), this basic knowledge could make a huge difference.

Enlightening them isn’t on our agendas during these encounters and I usually just leave it at that. When appropriate, with the CxOs who I know on a more personal level, I’ve tried to convince them of their incorrect or incomplete view of the software development process (usually to no avail).

Now, because I like to think via writing, and I really think I can provide value here, I’m making a series of blog posts about the various clichés and misconceptions I’ve encountered in this industry.

Sign up here for more enjoyable, insightful and (dis)informative posts!

Header photo by Moresheth, used under CC BY 2.0 / Cropped from original