Software Feature Cutting (Making Cuts)
When talking about cutting and cuts, one thinks of hurting and hurts if the cutting and cuts are being done by knifes or other sharp objects. Looking up "cutting" in a thesaurus gives you such words as, wounding, hurtful, unkind, spiteful, and harsh while looking up "cut" gives you slash, hack, and sever. Just using the words cutting and cuts in a sentence could make someone shiver a bit inside in the context above. We however, are not going to talk about making cuts and cutting things with knifes or other sharp objects. We are going to talk about cutting features from a software point of view and how those cuts come about and why they are needed and some of the caveats surrounding cutting software features of software under development.
Although we are not talking about cutting and cuts as done with knifes and other sharp objects, we can make someone shiver inside and generate some strong reactions from others. Mention cutting and making cuts to a Program Manager (PM) or Developer (Dev) about one (or more) features and you could get wounding, hurtful, unkind, and spiteful looks your way while being called names like slasher and hacker while the conversation gets severed short but not until after some really harsh words are spoken to you first. This reaction to cutting features from software I've seen and have experienced first hand and sometimes by a PM or Dev I least expected it to come from too!
Why would someone get so upset and do such things when talking about cutting features from a software program? Many different answers could answer this question but the three that I'm going to give here are, 1) the feature or features are ones that the PM and/or Dev like because they have worked on it for so long, they are comfortable with it and they just do not want to give it up or do it another way; 2) it is a kind of "pet feature" for the PM and/or Dev that they really enjoy working on and like any beloved pet, they don't want to give it up; or 3) there is a very strong believe that the feature needs to be in the software. (Take a moment and think about the main boss who has been there many years at the major software company of which you work. This main boss has a very strong believe that his pet feature needs to be in the software… now, you have to tell him that his pet feature needs cut. Kind of makes you shiver a bit doesn't it?
J) To any reason as to why anyone would get upset in having a feature cut from a software application, the logic of "why" the cut has to be made; "how" will this cut impact the overall project; "when" will the work come in with the cut and how over without it needs answered.
So, why would features need cut from a software application under development? The two primary answers to this question are, 1) the feature doesn't fit within the schedule and/or 2) it doesn't meet the needs of the majority of the software program's customers. Sometimes a time comes in software development that every feature originally planned to be included in the software just doesn't fit into the schedule like it did when the planning was done. The cost to keep the feature would hinder the proper completion of the schedule and as such it needs cut. There again, often due to changes in customer demographics or lack of customer input in the first place, the feature doesn't meet the needs of the majority of customers. It could be a combination of both where due to the time it will take to finish the feature, the customer need for the feature will not exist at the feature's completion date and so it needs cut.
One needs to make sure that the feature proposed cut doesn't break any key scenarios, makes the code base less stable or creates security issues if it becomes a cut. A key part about making cuts is to have a plan ahead of time to follow for making cuts if and when the time comes to start cutting features. Having a plan thought out well ahead of the time the cuts may be needed helps to not overlook the areas the feature touches and thus helps to not break key scenarios and make the code base less stable. You may want to consider having whole scenarios described so that if needed, the whole scenario and its related features and work items are known so that if it does come down to making cuts, you have the most information at hand available to know the impact made by the cut being proposed.
A couple of the biggest things to consider about the proposed cut if looking to save the schedule is, will it really save time and where will it save time? A cut for example, could save dev time but cost more in test resources and time and make the schedule go out even further. Again, this comes back to detailed planning prior to having to make cuts to help understand how much and where the time will be saved when making cuts. The best cuts save time overall but these are cuts that are sometimes difficult to find and often even harder to make.
The best things to do to help lessen the hurt of cutting follows: Have planned ahead of time to understand how the features work into scenarios and work items. Find out how the features, scenarios and work items interact with and w/o each other. Set priority orders on scenario, features and work items including the cut order and estimated amounts of time saved and where the time is saved if the cut is made. Understand when a cut can be made and when it cannot and the impact of making the cut at different times throughout the development cycle.
It's in our nature to want to finish something and to not want to cut it once we've planned to do it but, if we plan ahead and understand the cut, it could be the best thing to do to get things back on track. So remember, take cutting software features seriously even if it isn't done with knives or other sharp objects because there just may be more to it than you think and it could come back and hurt you if you don't.