If you do in-house development then you probably have first-hand knowledge of feature creep. If you don't know what that is, or you haven't seen it happen, then I envy you. It's an ugly monster and the bane of my work. The problem is not limited to in-house developers; it is particularly acute in that environment, though.
This is because development cost is a taboo topic in most in-house development environments. The developers and their immediate management don't want to talk about it because they don't want to remind senior management that in-house development is expensive. Senior management is happy to ignore it because they crave the finite control, costs be damned. So a game is played to balance the quality of the product with costs, where the quality is generally lower than a prepackaged system and the cost is generally higher. In general, this works fine. It helps keep developers employed and management happy.
The real problems start as the customization culture trickles down the management chain. Depending on how vertical the structure of your company is, you may have dozens of management steps between the top and the developers. Typically, when software is not a primary focus of the company, your developers and their managers will be quite low on the org chart. This puts them at a disadvantage when dealing with almost any manager and makes saying no quite difficult.
Therein you have the perfect storm: A situation where discussion about cost is a taboo, but the number of powerful voices calling for increased cost is huge. It's worse yet, though. When management's focus is not on software but instead specifically on how to make software work for them (as in, each manager personally) there is often little to no concern about the cost of feature creep to usability. In fact, usability is typically not in a non-technical manager's vocabulary. Outside of the developer group no one cares about usability, and often inside the developer group it is neglected because of the notion that client doesn't care.
Unfortunately, even if the user thinks they don't care about usability they really do. The difference between great software and passable software is often usability. The difference between a truly happy client and a client who is merely happy that development is done is usually usability. Software is supposed to solve a problem, to help a user achieve a goal. If it is too difficult to use it creates more problems than it solves, or it hinders the users from achieving their goals. At that point it should be considered a failure, though reality shows that this rarely happens.
Failed development projects, whether they are recognized or not, are dangerous. They put developers on shaky ground. They cause managers to think of the taboo of their in-house development: cost. If they aren't thrilled with the product then they will be far more likely to consider whether it is worth the money. The only thing that keeps this from happening is that they are often too egotistical to admit failures, but eventually if feature creep continues they will come around. When they do they will externalize the failure to the development group, after all it is their job to make this software and if it's so much more expensive then it should be better, right?
Wrong. There is little connection between cost and quality in software. Devs don't dare tell a manager this, except maybe as a last resort. Lest he add things together and realize that he could put company resources to better use.
Of course, most developers actually do want to put resources to better use. With less pet projects on their plate most developers will try to automate processes to save the company money. They'll refine existing systems to make them more efficient. In this aspect, in-house developers yearn to be more like system and network administrators; if you can't tell I'm there then that means I'm doing my job. Occasionally they might venture off course to test some new technology or try to solve a particularly complex problem, but for the most part a dedicated in-house developer is happy with the sense of accomplishment that comes when he or she knows that their product made a truly positive impact.
Developers have a responsibility to fight against feature creep. Don't buy into the false mantra that your job is to do as you're told. Your job, at any level of any company, is to act in the company's interest. That means to be truthful about costs and try to help management make the right decisions. There is no room for complacency in this. Feature creep is the developer's enemy and it is our duty to fight.
No comments:
Post a Comment