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.

Example

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

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

[...]

- mike@mountaingoatsoftware.com

As useful as user stories can be, they’ve never been right for every team. An exciting alternative f [...]

- mike@mountaingoatsoftware.com

Being a great product owner is hard. Here are the things your team wants from you to help them do th [...]

- mike@mountaingoatsoftware.com

Want to learn about Kanban? Here’s a complete guide to introducing Kanban into your organization. [...]

- Scott Hanselman

It's a double-meeting that! Get it? "Outlook?" Seriously, though, sometimes folks com [...]

- Scott Hanselman

I blogged about NancyFX 6 years ago and since then lots of ASP.NET open source frameworks that build [...]

- Scott Hanselman

My colleague Tara and I were working on prepping a system for Azure IoT development and were using W [...]

- Scott Hanselman

I've got a lot of different sound devices like USB Headphones, a formal Conference Room Speaker [...]

- Scott Hanselman

OK, fine maybe they DID teach you this in class. But, you'd be surprised how many people think [...]

Meta