“I’m a software developer, but I’m very bad at estimating a task’s workload. What can I do to improve on that?”

There are a couple of things that you might try, at different points in the process of developing software, or any complex activity come to that:

Task Breakdown

It is possibly (likely even) that you are not breaking your task down into subtasks. Eg if you have to add a new text field to a screen, you might be saying ‘oh, maybe a couple of hours’ to yourself when estimating. However, if you start to break it down you might end up with a list a bit like this:

  1. Modify database to add new field -1h
  2. Modify stored procedure to get new field from DB – 1h
  3. Modify stored procedure to set new field in DB – 1h
  4. Update repository code to retrieve new field from 2 above – 1h
  5. Update repository code to provide new field to 2 above – 1h
  6. Modify business objects to support new field – 2h
  7. Modify view code to display new field from business object – 1h:30
  8. Modify controller to update business object from view code – 1h.

So immediately you can start to see that your couple of hours is looking a bit tight, and you have not even added any tasks for the stuff you need like testing, code reviews, review with the business analyst etc.

And what about all of the stuff that we do as developers that does not contribute to the codebase directly?

  • Updating the task in task management system
  • Creating code branches
  • Merging changes
  • Running remote builds
  • Regression testing

Task Review

When you have a breakdown into sub-tasks like the above, you can start to record a narrative against the sub-tasks to record how long each took, especially stuff that you had not planned to have to do. Eg “table definition is in repository xxxx, took 45 minutes to track it down, 15 minutes to review with tech lead”.

When you have done a few tasks with a decent task breakdown as above you can start to get a feel for how long things take. Eg you might discover that changing a stored procedure takes a couple of hours to do the work but that typically another hour is spent on non-functional stuff like finding it in the source code base, reviewing it to understand how it works, cross-checking tables etc. All of this takes time and should be used to feed back into your estimates next time.

Finally you can take your detailed tasks narrative to see where you are actually spending time and how much. You can then use that to influence your subsequent estimates.

Advertisements

Writing simple c# code

I’m doing a lot of code reviews at the moment and thought I’d write up some thoughts on simplifying c# code.

What is simple code?

simple code is code that amongst other things
* fits on a single screen
* can be understood pretty much at a glance.
* has simple logic
* has well-understood side effects – preferably none
* often make use of LINQ.

Why write simple code?

  • Simple code can be understood quickly.
  • Simple code can be checked for correctness.
  • Simple code can be tested easily.

When are you done?

There are tools to measure how complex your code is (google Cyclomatic complexity for examples) but for my purposes, once you have met the requirements in the first list, you’re there!