≡ Menu
Pawel Brodzinski on Software Project Management

The Role of Time Pressure


One of great things about conferences is discussions which are food for thought pretty frequently. For some reasons, probably because its not-very-big size, ACE Conference is specifically good at this.

Sometimes it’s as if you’re talking with someone about the project you know perfectly. You could spend hours talking why it was successful, failed or whatever outcome it brought, except no one is willing to listen about the project that much.

Anyway, you could bet that nothing is going to surprise you about the project. Like with real money. And then you have a chat with a nice guy, such as Marcin Floryan, and you talking about the project for whatever reasons and suddenly, completely out of the blue, you have epiphany.

Suddenly you ask yourself, or are asked, another why and you answer the question intuitively and you’re totally surprised with what you’ve just said. It’s like wow, that’s oh so obvious, how come I haven’t thought about it earlier? What a dumbass I must have been.

So thanks to Marcin I had this kind of epiphany. We were discussing one of my projects which, from technical perspective, was very successful. Now that you ask – yes, it was the project behind the Kanban Story, but that’s not a reason this time. The thing we were digging around was whether technical excellence is a good investment.

It’s a problem of many teams: there is much pressure over them so they retreat to the good old hacking instead of keeping good engineering practices or even introducing them in the first place. They incur technical debt which they usually pay back during stabilization phase or maintenance.

So what happens when we remove time pressure? I assume here we talk about at least a decent team and people who know their craft. In the very project we discussed it meant longer development but most of the time regression testing, deployment and maintenance went quickly and flawlessly. Given that we were deploying like once a week it would be a real nightmare if it was otherwise. But then I know projects where every deployment takes a couple of weeks and it’s just a long painful stream of epic fails.

If you’re working on the project and you care about code quality in a longer time span you actually start reducing costs, as no matter how application grows cost of regression testing, deployment and maintenance remains basically flat. On the other hand, in projects with big technical debt tend this cost is growing exponentially.

And this is exactly the point when you start winning.

Let’s take a few steps back then. Why are we winning? Because we have low costs related to the final parts of SDLC. Why is it so? Because we don’t really have any serious issues with deployment and maintenance. Why? Because the code is good-quality. Why the code is that good? Because we keep it that way with our best engineering practices. And the final why: why do we have all these practices in place? Because there was no time pressure so we were free to adopt them.

The last why was my epiphany. For some reasons I haven’t really asked myself about non-merit reasons of introducing, or not, best engineering practices. Well, we kind of know it’s good to adopt best practices, after all they have the word “best” in their name so they can’t be bad, can they? But then it is so common that teams deal with time pressure and they sacrifice engineering practices on the altar of fast coding, also known as the altar of crappy code.

So well, if I had to point the root cause of the success in this example I’d say it was reduced time pressure. And the funny thing is, in the long run we were more productive than we would be if we had to drop our engineering practices.

I don’t say lack of time pressure is universally good. Actually I know quite many people who just need time pressure to be productive, but if you assume a decent team of good craftsmen it shouldn’t really be an issue.

in: project management, software development

10 comments… add one

  • Pawel May 10, 2011, 11:53 pm

    Generally you’re right Pawel, and I’m fully with you (I’m a project manager but deep in my heart I’m still a software engineer) but I’m afraid in most situations your solution is excellent and impractical in the same time: unfortunately shipping the product of an excellent quality but couple of months behind the competition, when the similar product (but of much worse quality) has been already on the market for a while usually means business failure… Take first iPhones or NK in Poland – the quality was crap at the beginning but they set the trend (with their crappy products), captured the market, improved over time and are the winners now.

  • Pawel Brodzinski May 11, 2011, 10:48 am

    @Pawel – I believe you miss the point. I couldn’t be further from advising to ship later for the sole reason of technical excellence. What I’m talking about going live at the same time, or earlier, just with better quality. In this very case, removing time pressure didn’t make us run slower over the whole distance – yes, we started slower, but before the finish line we were beating our time pressured alter egos and not even sweating.

    The trick is: usually if you avoid paying some cost at the beginning, when you’re compromising the quality, you pay it later and in this case later means “before going live.” If you know projects where acceptance testing and deployment were the most painful phases this is exactly what I’m talking about.

    Regarding examples you bring I totally don’t agree with the iPhone. It was state of the art phone of the time it was shipped. Sure, it had gaps but it was by design, not by accident.

    NK or Twitter (to take similar, but global, example) are just examples that you can go with crappy code at the beginning and get away, but it doesn’t mean they saved some time at the beginning. Actually both were victims of their success and I believe in neither case it was kind of conscious decision – “we’d cut corners on quality here and there as otherwise our competitors would be faster and will rule us out of the market.”

  • Szymon Pobiega May 12, 2011, 9:23 am

    I see two problems. One is, without any time pressure developers have a tendency to gold-plate their designs which has negative effect on the quality of the solution. Gold-plating usually mean generalization of the solution, creating abstractions and stuff like this. Gold-plated software is harder to maintain because it is more complex.

    The second problem is, as Fowler pointed recently, as soon as you start trading quality, you loose. It’s like war games — where the only good solution is not to play. From my experience, it is not true that, even in the short time horizon, you can write low quality code faster than high quality. Good devs don’t write crappy code, even if you ask them to do it. They simply don’t know how. There is no switch or slider on developers back that allows PM to adjust the quality of code she produces. You always write the highest quality code you are able to write at the moment.

  • Pawel Brodzinski May 12, 2011, 11:56 am

    @Szymon – Developers have tendency to gold-plate architecture no matter how much, or how little, time they have.

    Regarding quality of code I think about code itself but also about all the practices you may introduce or try if you have enough time. Besides if you ask many managers whether you can try things like pair programming, code reviews and such you’ll hear that there’s no freaking way as you have no time for such things.

    And I’m talking about reality around us. I know it should look differently but we don’t live in ideal world.

  • Szymon Pobiega May 13, 2011, 12:09 am


    I wasn’t talking about the ideal world. Have you seen good developers writing crappy code because of time pressure? I haven’t. If you see a dev, who you think is good and he reverts to crappy coding practices when you introduce a time pressure, he wasn’t a good dev in the first place. When you internalize the knowledge, there is no way to bypass it when you work. That’s why you don’t revert to crappy (micro)management practices even in case of time pressure and work overload.

    As for gold-plating, I think the idea of standard sized features you introduced couple of posts before would be great tool for fighting this syndrome. I mean, a deadline for a whole project won’t help you in fighting gold-plating, but tight (but reasonable) estimates for each feature/task/work item should.

  • Pawel Brodzinski May 13, 2011, 12:26 am

    @Szymon – I guess we should start with setting up the ground: what good-quality code is. But then it would be different depending on who you talk with.

    On the top of that we have practices which we can also put into dispute – whether they really help or not and if they do to what point they are helpful and how much time one should invest to introduce them in a team.

    It isn’t about writing crappy code – it is about building your toolbox.

    Think of a couple of pieces of code which are identical. One was written using TDD and was heavily refactored along the way and another used test-after approach but there was more focus on design so there was less refactoring. Now, which approach is better?

    The answer is of course: I can’t say. Besides what “better approach” means after all. But you see the point – it’s not about code itself. It’s not about the goal – it’s about the journey. And you can get to the same place with different means.

    To make argument complete – I don’t think the solution which takes least time is the right choice here. Well, sometimes it probably is as you may optimize for time consumption. But also you can optimize for highest percentage of success, which probably means over-investing in some projects etc.

    This is exactly the grey area I tried to cover. I believe that with decent developers sharing the power over that land (which basically means reducing time pressure) is a good way to go.

  • Szymon Pobiega May 13, 2011, 2:28 am


    There are two probably equally popular approaches to building the toolbox/sharpening you saw.

    One is reducing the time pressure so that devs can experiment with new practices and techniques at work. The second one is basically when at work, you have to be productive and that’s why you have to learn in your private time.

    I don’t know which one is better. During the last few years I drifted between them a couple of times. Probably the answer is to combine both. That means you have to have some time pressure and some freedom. There are things you can’t learn at home and that’s why I agree with you that lowering the pressure can help the team to develop new and better ways of creating the software.

    But on the other hand you can’t give them too much freedom. You pay devs for being productive. Learning is a critical part of our job and all devs should know this. After all surgeons don’t learn in the operation room, and lawyers don’t learn in the court. They learn at home and then gain experience at work.

    In software development it means, I would expect my devs to know everything about the theory behind pair programming when they come to work. Then I would allow them to practice it and gain experience during the course of the project. On the other hand, in case of TDD I would expect them to know it both in theory an and in practice because they can learn it at home.

  • Pawel Brodzinski May 13, 2011, 6:37 am

    @Szymon – I guess there’s no silver bullet there, as usual. And as usual you can bring it down to people. There are people who would do very little to build their skills in their private time, yet they can still be good team members and craftsmen.

    On the other hand we definitely should value very, very high people who invest in their craft within their free time as it shows their commitment and seriousness about the path they chose.

    But it doesn’t mean I have to know everything about Prince2 in theory even though I’m dealing with project management stuff. If I joined organization using Prince2 I’d probably learn it at work. On the other hand I do invest lots and lots of private time to sharpen my saw, so you can clearly assign me to the first group.

    Anyway, you’re right – it’s probably kind of mix. My point was was that we usually deal with too much pressure and not too little of it. Actually I know very few teams which need more time pressure.

  • Szymon Pobiega May 13, 2011, 10:02 am


    You’re right, there is a lot more teams that have to deal with to high pressure.

    On the other hand, what I see quite often is dealing with this too high pressure by letting the next project be ‘carried out according to the proper engineering practices’ which often leads to gold-plating and over-engineering. The end result is teams often jump between two extremes while they should seek the sweet spot in the middle.

  • Pawel Brodzinski May 13, 2011, 2:18 pm

    @Szymon – I’d just say that if you visited both extremes you’re more likely to come up with the right approach so that’s not that bad after all. Besides you need to over-engineer at least one project to learn what over-engineering is ;)

Leave a Comment