Some of these turds are simply our own doing, others driven from external influences of the team.
Why Get Rid Of Unnecessary Software
While there are just shy of a bazillion notable reasons dead code should be exorcised like a demonic possession, I'll only hit on a few before moving on to how they may have got there in the first place.
Expensive Scavenger Hunt
Few things are more frustrating and costly than to be investigating a bit, or massive amount, of code in the attempt to understand what it's intended purpose is only to later find it is never called/used/wanted... That, my friend, is a real kick in the knackers and just about enough to bring an otherwise collected professional to tears or rage. This typically isn't a one-man/women show either, often it involves reaching out to various team members which balloons into a series of suggested 'you should talk to ...' domino chain. By the end, these non-productive Easter Egg hunts cost you money and time, two things that come in short supply these days.
Documentation Recurring Costs
Like that pyramid of dried out paint cans every homeowner has in their garage keeping clutter costs you money, directly or indirectly. Unused features still require, or should require, documentation and support efforts. Documentation evolves no differently than the product itself and as the documentation is updated the cost of associated unused features comes along for the ride. Like sanding a block of wood before tossing in the fireplace, that's time/effort completely lost. Some will simply take the tact of not updating documentation revolving around unused features and that is just denial, if you can't take pride in your product and half-azz it how do you expect your users to? Good documentation should flow, have consistency and continuity. Simply ignoring sections is a cop out for making the right and tougher decision and still will cost you money. Uncommon features and controls will eventually be found by curious users, resulting in questions and support queries. Hide them away, like your children's Christmas presents and they are still sure to be found.
Testing Recurring Costs
Perhaps you're lucky and the code-base for unneeded software never changes. Then, your testing costs are pretty limited; unit test time, pure automated tests....cpu cycles come cheap. I've never, in my 20+ years, worked for a company that didn't have extensive manual testing efforts. Even if not a single line of feature code changes, there is still risk the feature no longer exists. Indirect dependencies; libraries, data feeds, latencies, operating system changes...these can easily impact feature functionality even if the feature code itself never changed; the whole reason you have a QA and Testing departments. "We just won't test the unused features"; same band, different tune...same cop out.
Worse, suppose the feature code changes, perhaps due to replacing a core library that sprinkles itself throughout the system. Polish that firewood.
Development Recurring Costs
Direct development recurring costs are pretty simple, hours x rate = buttload of money. If you're steadfast in keeping unwanted features then it's just desserts that your corporate wallet takes a hit. Indirect costs can be on team morale. Good teams take pride in their work and you can visibly see the pride drain from their eyes when they find that they'll be working on an unimportant feature. It sends a message, that their time isn't worth doing meaningless tasks.
Pride In Your Product
I'd argue that one of the greatest motivators for a team is taking pride in their product, not the schedule, not the budget, not the revenue... 'Purpose' is the latest lingo and is perhaps the strongest separator between a 'job' and a 'career'. Clean and elegant rather than clumsy and complicated; unneeded feature-creep results in a clumsy product, and soon will take on a smell like rancid meat.
How'd It Get In There In The First Place?
Proof-Of-Concept Retention
"Beth, I need you to prototype XXX"; that's how the activity normally begins. Prototyping is necessary for any number of reasons: establishing market interest, generating a rough development effort, marrying two independent systems... The promise is always the same, stitch in a prototype and we'll refactor/redesign it once we know we want to move forward with it. Strong leaders hold up their end of that promise, lesser ones won't. Worse, if the proof-of-concept is deemed unwanted; good leaders will orchestrate the removal of the design, lesser ones won't.
Sales Feature Request
Sales folks sole purpose is to drive sales, bring in revenue and seek commissions; period, full-stop. No cash, no company.
If you've ever been frustrated standing behind a customer in a fast-food restaurant who simply can't make up their mind then you've witnessed the collective whole of customers sales folks deal with daily. As a whole, people are indecisive about what happy-meal they want, imaging how much uncertainty they have in buying a product 10x, 100x, 1000x in cost.
In fast-food speak, customers think they want a quarter pounder but not with the condiments you have...instead they want Mango salsa. So, the cashier rushes out the door, jumps in their car, drives to the nearest grocery store, finds they don't have it, drives to another.....finally returning and adds this new condiment to a freshly prepared burger...bags it, rings it up and along the way the customer changes their mind and decides they don't want a burger. The customer doesn't have any skin in the game and can back out with limited consequences.
"Boy, we can sell the crap out of this in [Russia, France, India, China,...]", it only needs this one thing..... Then, the market is found bare and the feature remains as a cruel ongoing reminder of a feature failure, always.....ALWAYS....with a promise "it'll take hold, give it some time".
Contractual Obligation
You're a young man venturing into the lawn cutting business after school. You've got no customers, endless energy and a drive to make this new venture work. After encountering no after no after no, weary and desperate you approach homeowner that is willing to purchase your services....with one condition....you use a push reel mower. As your greens-keeping empire grows and your relationship with this customer continues....there will be a day when this constraint will begin costing you more than it's worth. Loyalty, contractual agreements or simply a gentleman's handshake can keep you maintaining features that no longer make strategic sense. Early customers often find a willing and desperate team that is willing to specialize their product simply to get a sale/relationship. Cutting the cord is difficult at best.
Reimbursed Feature
You hear horror stories; a customer kicks in a modest financial cost-share for a feature development effort. Then, an eon later the feature remains, sometimes isn't even used but wary to be removed. Removal would take a discussion, perhaps a buy-back and likely a complicated endeavor so simply avoided. Still a wart, hopefully the financial kick-in was substantial but often is modest, and certainly not in the ballpark of the on-going un-ending recurring costs to maintain.
'Spec Out'
I was unfamiliar with this term until I worked in the DOT commercial sector, but I suspect it's relevant elsewhere.
While perhaps well-intended, regulations and constraints often are misused...it's human nature. If you're a 'true blue Ford aficionado' and know....deep in your soul....that Fords are a superior vehicle you'll feel a sense of responsibility to procure these bullet-proof vehicles for your fleet. Meanwhile, every vehicle manufacturer wants a seat at that table.
So, you use product requirements to your advantage. Say Fords have a slightly better fuel efficiency....you add that to your product requirements; 'must provide 20+ mpg'. You can justify that, fuel costs are substantial for your fleet.....
To be "spec'd out" is just slang for not meeting the requirements of the product requirements/specifications. It's a cat/mouse game of vendor/purchaser and can be a contributor to unneeded/unwanted/incomplete features. The vendor-preferred product X has a web-interface, a web-interface is called out in the spec....we need a web interface even if the users never want or use it.
Regardless of whether the feature is used or needed, features can be required simply to get a seat at the table. Worse...many of these features are never really wanted and when that's known the emphasis on the feature is "something", sometimes without even caring if the feature even works.
The cynical side of me feels the ever-growing specification is intentional, but whispers of an alternative reasons drop in occasionally. When you're selecting a tool for your team, 'more' can be mistaken for 'better' and as a key decision maker you want the best for your team. A Swiss Army knife with 12 functions is better than one with 8...right? Unless you know that 4 of the additional functions are of no use to your large and diverse team...isn't it safer to pick the fuller-featured one? Who has the time to survey their team with what they really need...just get 'em the bigger one.
Closing
Likely stuff you already know and as you see I offer no detailed solutions. Often the motivation for retaining dead code is a couple levels up in the org chart, the consequences left to be dealt with by the engineering oompa loompas.
/shrug
No comments:
Post a Comment