Software Engineering 101: Cutting a feature sooner is better

  • Article

Isn’t it funny how we need to be reminded of the basic principles of software engineering on a fairly regular basis? Here is a simple test that I think 100% of you will get right, but we tend to fail it in the real world 9 times out of 10. Which is better:

  1. Cutting a feature at the last minute after you have already wasted spent many hours designing, testing, reviewing, documenting, securing, making faster\smaller and possibly even slipping the schedule.

-- or –

  1. Cutting a feature just as soon as you can tell it is unlikely to come together with the time and resources you have.

Clearly, B is better. It saves all that time and resources and quite possibly it makes you able to ship sooner with better all around quality. Some folks would like an option “C” where we don’t cut the feature at all… Well, that is just not an option. If your experience with software projects has been anything like mine you know that you have to cut to ship. I have worked on zero software projects that we didn’t have to cut something to make the date – oh, that is not right… I guess there were those projects that never shipped ;-).

Now there is some pretty standard pushback to this line of thinking, let me deal with a couple of them:

  1. “But the feature will be ready in just one more day/week/milestone”. Most of the time, we underestimate (by a lot) how much it will take to bring the feature in. Sure, set reasonable deadlines, but be sure you know what failure looks like. What do you expect to see tomorrow, in the next week or next milestone to make you feel like this is on track? What would make you feel like it is not on track?
  2. “But this is a must have feature”. That is my favorite one…. These sacred cows are often a large drain on the resources of the team (as they are so important to have) but avoid the really hard questions as who could imagine not shipping this feature. But, at the same time they are the important ones to cut. You can save only so much by cutting the small features, you often need to cut the big features to “land the plane”.
  3. “But how can I know a feature is unlikely to make it.” It is super easy to over think this one and make it much harder than it is. I am not asking you to be Nostradamus or anything. Simply ask yourself: “if we continue at this rate, when will this feature be ready to ship?”. How many new bugs are being found, how fast are we fixing them, what are pre-release customers saying? How is the stress testing? How are the dependencies?

 

Cut early, cut often... Don't wait for it to be too late to mater!

 

 

What are your thoughts? Have you worked on software project where you didn’t cut soon enough? What would you do differently?