Software Engineering 101: Cutting a feature sooner is better


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?

Comments (13)

  1. Matt says:

    I’d agree 100% with the "cut early, cut often". We primarily develop custom financial applications for investment banks, and all to often traders want x, y and z features, but in reality they can do without from day 1. Hence, cutting early and actually delivering to the trader is beneficial, since it means they can start to use the system and make money (plus we avoid the "late delivery (failure)" tag). But then custom financial software is very different to product development at Microsoft 🙂

  2. Lee says:

    When starting development on some features even at the start we have ideas what parts can be cut if necessary. We wrote a custom reporting system for an new accounting application and we envisaged also having a GUI designer for it. Ultimately we had to drop the feature luckily before much coding had started. We made do with an XML editor with auto complete which did the trick.

    On a negative side we had a meeting over half way through development with regards to some versioning system that was going to be implemented. All the alarms were going off that this *feature* would drag the release date back if indeed it was even possible. At that point to some it became a point to prove that we could have this feature in the product and that group persuaded the powers that be that it was achievable. Suffice to say the feature never made the light of day and cost tens of thousands of pounds in wasted effort. Lessons learnt…. Hopefully 🙂

    Keep up the good work with the blogs you really hit the nail on the head with this blog entry.

    Regards

    Lee

  3. “But this is a must have feature”.

    On the other hand, I really respect management who are willing to delay a product to make room for a feature to complete. Sometimes, it takes more courage to delay a product than to cut a feature.

    It is all about priority. Ship a mediocre product on time, or ship a great product late.

  4. "I really respect management who are willing to delay a product to make room for a feature to complete."

    And since it takes much more courage, it’s usualy harder to make the business people understand that integrating a feature really would need more time…

    If I think in terms of features, I’m personaly in my business mood anyways, because these things are more like management issues then software engineering.

    There is little in terms of engineering you can do to win a feature or loose it for one specific release, can you?

  5. theCoach says:

    The one reasonable exception I can think of is to do some of the work to design for the extensibility that will allow that feature in the future. If the feature might make it into the product, it is not a bad idea to do the usability work that would make it easier to add in the future (often this is just a part of good, forward thinking design, but specific needs can help focus).

  6. @Benjamin J.J.Voigt

    Exactly, that is why I respect management that understands software engineering.

    @Brad Abrams

    You see, this is not Software Engineering 101. It is more of Software Management 101.

  7. Chui Tey says:

    We had to port our product to the web and it was increasingly clear that we will not be able to port the entire feature set from a Rich Client to the web, and it takes great courage for a manager to say we will cut a feature, as that will mean that existing users will see that the web port will not be able to do some of the tasks that they were able to before. Of course, for new clients, this is not as big a problem.

  8. JMazner says:

    A favorite quote from a product team manager at MS: "I know we’ve turned the corner because every day we manage to complete one day of work." He contrasted it to the pre-cut phase, where for every week of work they did, the schedule would expand by another week to accomodate all the extra work they realized they’d have to do to finish up the features.

  9. Louis Parks says:

    This isn’t the only option, of course. We could also learn to be better designers / architects. In such a case, we’d be better able to gauge the time required to implement/test/release the feature set. Absent this, however, cutting features is a good option.

  10. Larry Rix says:

    Our business managers are very grooved in to the notion of agile and iterative development. They have buy in on the fact that they really don’t know from the beginning exactly what they want. They see clearly from the evidence of the process that they know notions, but not details. Details are developed over time and the process of software development is more evolutionary engineering than something you can predetermine fully. They are quite comfortable with picking their revenue battles wisely and depending upon us as their IT people to give them good feedback about what is responsible and reasonable in constrained time and budget. We took the time to not only educate our business team, but to show them by example and work as a team member with a shared objective. Not only did they buy in to our vision of the software development process, but we determined to show them that we bought in to their business vision and that our common goal is to make money with the best product we can for the time and money that can be devoted to it. Our discovery has been that this is not just a technical equation, but a human one as well. Business people are not stupid, they are in need of a partner that will play ball with them and not just see software development as an end in and of itself. As IT we exist as a team player. Choosing to come on board the business side as a willing team player using the tools that we know work — Agile and Iterative development — we shoot for the I-win-you-win-we-all-win scenario and what is really amazing is that no one is unwilling to sacrifice when everyone seems to be sacrificing for the common goal.

  11. Achi Ifeanyi I. says:

    I like to know more on software development process.