How do you do planning for small deliverables at work?

Question

Hi,

If you are given a small programming deliverable at work (Say, nothing more than 2 weeks work), how would you plan the task to ensure you don't rush in before understanding everything (including an existing codebase)?

I would write a brief document explaining what I think each class/method does and how, how I would modify each class in any existing codebase to how I feel it should be to meet my needs, and of course read the comments.

Are there any other suggestions? This is a big habit to get out of for younger professionals (doing the right sort of planning).

Thanks

Answer 1

Generally I'd give a time estimate where things will be checked to see if things are on track or not. This is a way to see if things are going down the right path or not. This is presuming the task is something that would take at least half a day as if it could be done in 4 hours or less, then it may be worth just doing it and then see if there is extra stuff to do as requirements can change at times. Documenting everything can be overkill if the task is something as simple as writing a small application to download thousands of images which will be used once.

2 weeks isn't that small to my mind. That's possibly 80 hours of work if one person is doing a 40 hour work week and doesn't do anything else. Lots can happen in that time and a lot of time could be wasted if someone goes down the wrong path on it. This is why I can like the idea of Scrum where in a daily standup some things are covered that may prevent someone from going down the wrong hole.

Answer 2

For smaller pieces of work I find it very important to be very clear on exactly what the deliverables are. There seems to be some sort of inverse correlation between size and assumptions of intent. On a bigger task people will be more ready to acknowledge that there is ambiguity and the planning is required, the smaller the task, the more everyone assumes that everyone else just knows exactly what is to be built.

What I've found is that deliverable usually break down into:

• Detailed business rules (preferably some sort of light weight spec)
• Test plans (how will the end users know that the old and new business rules still work)
• Statement of methodology (will this development include unit tests etc.)

The next step once you have gathered agreement on exactly what you will build is to then define how it will be built. This is what I'd call a developer's design phase.

This is very similar to your comment on examining each class and method to change. The things being investigated should be around the current behaviour, in particular any side effects of each class needing to be modified.

• How do these methods behave? Is there logging or class level behaviour that the methods modify?
• How do these methods respond back? If possible check consuming code. At the very least look for things like the approach taken to notifying of errors, if the code throws exceptions now, it should keep doing that since you don't know if consuming code is expecting that.

The above investigation should also be communicated back to users where relevant. For example, they may not know that an existing piece of code emails users, and might not want the new code to do that, or they may be assuming that the existing code persists to a datastore.

I'm usually happy to start cutting code once I've gone through the above. The key thing is to avoid any surprises in the development process. On a small piece of work an unforseen complication can blow out a timeline by 100% or more quite easily so the investment up front to mitigate that is worth it.

---

One caveat on the answer above is that this really only deals with a waterfall SDLC or with making changes to an existing codebase - more agile projects deal with the understandibility and management more small change as part of their natural process.