RoR-e

If you haven't seen The 15 minute E-Commerce Site CLICK HERE


I'm currently looking for Contract jobs, Contact Me if you are interested. Dave.

Justifying TDD/BDD & Technical Debt David Henner Feb 12

Post a comment

Yeah I said a dirty word.

SCHEDULING

So here is the scoop. At some point you will need to give someone a schedule. I still stand with the idea of having Goals not Schedules. Goals are for your team. Unfortunately, Schedules are for Venture Capitalists.

The first rule for scheduling is that the schedules are not made to be met. Schedules are made understanding what needs to be done.

Given the 1st rule, you should not spend a lot of time on schedules. That said if anything you schedule takes longer than a month or two you should still break it up into sections (preferably 2 week sections or less).

What you aren't doing correctly!

The one part of scheduling that people never take into account is maintenance. The day your app goes live you might schedule 25% of your time going toward maintaining production.

My first reaction is 25% is probably too low. Your first few weeks after launch at least 50% of your time concerns maintenance. Even if you don't have bugs your users are responding (hopefully) and if they are responding you should spend some time reacting to their concerns.

Lets say 25% percent is an accurate amount of time devoted toward maintenance. One of the biggest issues is that you now continue to have a constant amount of time devoted toward maintenance for the next year of your schedule. Why is this an issue?

Every time you release a new feature the % of maintenance must go up.

This should not come as a surprise. As you have more features, you have more issues. So to schedule correctly your schedules should look like this:

  • Task-1 ( 2 weeks + 5% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 15% maintenance)

Yes some tasks will not need maintenance. An admin interface will commonly have little maintenance issues.

Lets say another 10 weeks pass. Looking at the above schedule One might think that after 10 weeks you could finish all the tasks. This isn't true because in the beginning 25% of your time is spent on maintenance. Then as you progress your maintenance time grows to 57% of your time.

Pretty soon all of your time will be spent on maintenance. This is when managers say we don't have enough developers. NOTE TO BUSINESS FOLKS => LEARN TO STOP THE CYCLE MAINTENANCE CYCLE.

Developers sometimes label this as technical debt. Unfortunately business folks don't understand technical debt. They do understand schedules not being met. So we need to explain to them in terms that they understand. Unfortunately a gantt chart doesn't measure your schedule very well.

Now it's time to Justify Best Practices?

Give a VC or business guy two or three schedules. Don't focus on the time it takes for each task or even the maintenance. Your first schedule is each task without TDD. It might look like this:

  • Task-1 ( 2 weeks + 5% maintenance)
  • Task-2 ( 1 weeks + 4% maintenance)
  • Task-3 ( 2 weeks + 2% maintenance)
  • Task-4 ( 4 weeks + 12% maintenance)
  • Task-5 ( 1 weeks + 15% maintenance)

Your second schedule is each task with TDD. It might look like this:

  • Task-1 ( 2 weeks + 3% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 10% maintenance)

You notice the reduced maintenance but the reality is maintenance is still rising at a good pace. The third schedule you need to add a task to reduce Technical Debt.

  • Task-1 ( 2 weeks + 3% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Tech-Debt-Task-1 ( 1 weeks - 5% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 10% maintenance)
  • Tech-Debt-Task-2 ( 1 weeks - 10% maintenance)

Unfortunately you should not work off technical debt until weeks after you create the debt. Scheduling more time up front for tasks just doesn't work. There are a couple reasons for this:

  1. You always have "ah-ha momments" after the project is complete. Sometimes well after the task.
  2. Some of the debt isn't learned until you have more information. (like when you are asked to build something on top of the original code)

TDD / BDD / working off Technical debt will never remove the need to hire more developers. But using this technique it is much easier to justify using best practices. You will be able to "scale your developers." You should also point out to the business folks the amount of man hours spent on maintenance / new features / training / management with and without best practices after 6 months & 1 year. This is what your VCs and other business folks understand.

Your next step is to justify not having schedules. I haven't thought of what to do about that yet. Luckily I have been successful at using a few curse words to justify not having schedules. =)

Comments are closed