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

I wrote 25 blog posts during 2018. In case you missed some of them, here are the most popular. [...]

- mike@mountaingoatsoftware.com

The iterative and incremental nature of agile makes an agile approach seemingly less compatible with [...]

- mike@mountaingoatsoftware.com

Velocity can be great for predicting how much a team can deliver in a given period. But it needs to [...]

- mike@mountaingoatsoftware.com

Succeeding with agile isn’t just about knowing where to start, it’s about knowing where to go next—w [...]

- mike@mountaingoatsoftware.com

Here’s what to do when facing a complex user story that cannot be split but is too large for one spr [...]

- Scott Hanselman

As I said on social media today, it's 2019 and I'm updating the Firmware on a Zune, fight [...]

- Scott Hanselman

I'm going to try to finished my Relationship Hacks book in 2019. I've been sitting on it t [...]

- Scott Hanselman

My son and I were working on an Adafruit NeoTrellis M4 Mainboard over the holidays. This amazing lit [...]

- Scott Hanselman

I'm on vacation for the holidays and I'm finally getting some time to play video games. I [...]

- Scott Hanselman

I blogged about DOSBox five years ago! Apparently I get nostalgic around this time of year when I [...]

Meta