The Dangers of Planning Time on Software Projects

Home » Agile Techniques » The Dangers of Planning Time on Software Projects
Photograph of columns in old building

Agile techniques favour responding to change over following a plan. I can’t remember where I read it, but I took it years ago that Agile was about staying focused on user functionality over and above trying to plan every last detail because it had been acknowledged that it isn’t possible to do that in a changing environment. Time planning is the subject of this post.

The Dangers of Planning Time

I have worked for many customers where the primary focus of management is the time taken by developers to create the software. As though development is some kind of production task. I believe that the only production we do is publish the project or cut the cd at the end of development. The reminder is design, not production.

The danger of trying to plan time taken over functionality, is that faced with having to justify every minute spent, developers (especially if not architecture aware) could take short-cuts that compromise the architecture.

This sounds crazy as I write it but it happens. If the culture is for developers to look good by getting work done quicker than others, some are more likely to take short-cuts that result in less code but poorer architecture with more dependencies. The end result is the software is quickly reduced to a complex tangled mess. The same developers can then go on to defend their actions, e.g. that they created performance improvement that obfuscated the code when they had not tested the benefits beforehand. This makes them sound good to their managers who think they are working with an expert when the reality is that the developer needs further training as they are just making a big mess.

This can all come from focussing on time rather than functionality. In the Agile world, a complete feature can be removed from a sprint if time is short. Or a more aware developer could take a short-cut that does not compromise the core architecture. Agile techniques have more than one level of protection against this type of practice which I may blog about in future.


An example of the dangers of planning time and trying to control it to the nth degree is as follows: Say for example, the managers say that they are “Agile”, they will allow for an hour of code review every four hours spent on coding. Sounds reasonable? (apart from this isn’t Agile and is totally arbitrary)??

The programmers work on this basis, filling out their time if no review is required, so they don’t get accused of not reviewing the code properly, or skimping on reviews if there isn’t enough time. I don’t need to say what the end result is.

The correct way to do this is to give the team as much time as they need for reviews, and measure the time taken. Thus as a manager you can learn the true velocity and the true situation from the times actually taken and if the software actually stands up subsequently.

I would say that as a developer, if you can’t find a WTF in five minutes of looking, you are most probably done, so reviews should take as long as needed until you reach that point…

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!
One Response to “The Dangers of Planning Time on Software Projects”

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Top Posts & Pages


Recent Posts

Recent Comments



  • Mike Cohn's Blog
  • Scott Hanselman's Blog

Our virtual Certified Scrum courses aren’t tedious 16-hour Zoom snoozefests. This video shows what t [...]


Time pressure improves productivity & quality…up to a point. Learn how short iterations and accu [...]


Boring retrospectives or ones in which people are afraid to speak the truth are just two of the most [...]


If you really want to speed up your team, sign up now for Scrum Prime and have everything delivered [...]

- Scott Hanselman

During the Microsoft Build keynote last week - that you can watch free online here - we snuck in a L [...]

- Scott Hanselman

I've been spending a lot of time with Docker lately. Docker Desktop on Windows is great and get [...]

- Scott Hanselman

I was offered a Surface Book 3 to use as a loaner over the the last 5 weeks. I did a short video tea [...]

- Scott Hanselman

Last year Microsoft rebooted PowerToys and it's open source and on GitHub. It's a few mont [...]

- Scott Hanselman

Microsoft Build 2020 is upon us, registration is open NOW. Stop reading this blog post and go regist [...]