The Burden of Features in Software

I?ve been removing a couple of dead features this week. You know, those features that senior people in organisations like to tell epic war stories about. Those mighty conversations at dinner parties, where a person involved talks about all the pain and sorrow, about how a particular capability ended up in the software, how (crappy) it got implemented, etc ? . Everyone at the table is laughing. Some of them who were also there, adding more personal anecdotes to make the story more tragic.

But the good news is that these features are no longer relevant to the end-users. In some cases, these features don?t even work correctly anymore. But they are still there to haunt you as a software developer. They wander throughout the application as ghosts. Usually they are totally at odds with the current architecture and/or design. Whenever I come across something like that in the code, I turn it into a personal crusade to get the code out as soon as possible. Removing dead weight is equally important in our profession as adding new code. But how on earth did this feature get into the code base in the first place?

In a previous post I wrote about product and project focused software. In all cases, adding features to software adds a burden. There?s not only the cost of implementing and deploying it, but there?s also the (hidden) cost of maintaining it and further evolving it as the capabilities of the software grow or when the architecture evolves through time. Then there?s also the added complexity for the end-users, need for documentation, etc. ?

In my experience, there tends to be more awereness in organisations where there is some form of a product focused mindset compared to ?project? organizations. In ?project? organizations, a particular feature might be necessary in order to succeed with a project or two. Afterwards, there might no longer be a need for this particular capability, but a (new) need for something else might arise. They pile up feature after feature after feature until they end up with a Big Ball of Mud. In these kind of organizations there is no threshold for adding new features.

I consider being cautious before adding new features a good thing. Adding capabilities over time that are harvested from actual needs tend to be more useful anyway compared to ?we need this thing, and we need it by yesterweek?. As described in my previous post, things are usually no that absolute. Most organizations sit somewhere between completely ?product? focused and completely ?project? focused. But the really excellent ones refuse to add new capabilities to their software until not adding it becomes almost unresponsible.

The thing is that we should create awereness that crafting software is quite a fragile proces, both with ourselves as with our stakeholders.