Is Endurance a Good Quality in Software Projects?

The ability to endure hardship without complaining is often considered a positive feat associated with “endurance” or “stamina”. However, endurance seems to be a double-edged sword (not only) in software projects. An appeal to speak up in software projects instead of just enduring the status quo.

The Enduring End User

Everyone who has been involved in a long-running or a maintenance software project knows this type of end user. He has been working with the software day in day out for years and knows all the pitfalls and bugs. He also knows workarounds for most of the pitfalls. Those workarounds take more time than originally intended, but he doesn’t mind. He knows that the working day is over at 5 pm. So he endures.

While the Enduring End User is not happy about all the bugs in the software he works with every day, the Outspoken End User literally hates them. As soon as someone tells him about some new workaround to be used to dodge a new bug, he grabs the phone and calls the project manager to express his disappointment in the software and submits a request to fix the bug. If no one reports the bug, how will it be fixed, after all?

The Enduring Developer

The software developer finds himself in the middle of things when working on a software project. The end user confronts him with new requirements regularly. The project manager assigns tasks and wants to know when they are done. There is no real software development process established in the project, so the developer manages all the incoming requests as fits best. He wants to perform good, so he finishes his tasks quickly. He is not always happy with what he delivers but it is like this in all software projects, after all. So he endures.

Meet the Outspoken Developer: he speaks up when he realizes that he cannot complete his tasks in acceptable time and quality. He says “no” if the project manager wants to assign him additional tasks. He alerts the project team to the missing development process. He alerts them again when nothing happens after the first time. He may not always finish his tasks in the time expected by the project plan, but he will deliver better quality.

The Enduring Project Manager

The project manager has the task of negotiating between customer (end user in many cases) and project team. Both parties are annoying at times. Especially if they just don’t shut up and keep pointing out things that could be done better within the project. But he knows how to deal with those rebellious sentiments within the project. They just have to be endured until forgotten.

The Outspoken Project Manager, on the other hand, adresses the proposals of other team members and stakeholders. He talks them through and by discussing them finds a solution that the project benefits from in the end.

Endurance? Yes, but…

The above descriptions can certainly be transferred to many more roles in projects (and not only software projects) and they are certainly a little exaggerated. However, be aware that it is easy to fall into a mode of just enduring a project instead of actively participating in it since actively participating means to step on someone’s toes now and then… .

Nevertheless,endurance is necessary: How often do we delve in foreign code trying to find a solution to some wicked bug we just can’t get our head around? In a situation like this you have to keep calm and endure the time-consuming process of finding and fixing the bug. The important thing is to not just move on after this tedious bug fix. Ask yourself what the cause was that brought you into that situation. What can be done better? If you know something, speak up and talk to people about how to make it better. Perhaps even set up a white board where proposals like this can be posted and discussed in the team.



  1. Bruno Cassol

    I agree with your opinion.
    BUT 100% of the projects/companies I’ve worked on would consider the outspoken and perfectionist developer not as productive as the one that delivers “quick fixes”.
    Even tough the “quick hax” developer deliver bad code sometimes. Sadly it is just more important is that it “delivers”.
    My income got considerably higher once I understood this phenomenon.

    For me, the trick is to “deliver” at work but “to do it right” on personal projects and keep studying. This way I don’t turn myself into a mediocre developer.

    • Tom

      Sadly, you are probably right in that the “delivering” type is more in demand than the “outspoken” one. This is probably true in most disciplines and not just in software development. However, I hope this will get better in time with current movements like “Software Craftsmanship” and Agile.

      I believe there is a difference between “outspoken” and “perfectionist”, though. You don’t have to be a perfectionist to speak up when things are bad. You probably cannot be a perfectionist in most commercial projects, but you can be outspoken to make things better, if not perfect.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s