Not often does literary world of The New Yorker and the uber-logical world of technology intersect, but Heather's McHughes poem "Hackers Can Sidejack Cookies" has given me hope this will happen more often. In the poem, Heather talks about "the banana problem"
A buttonhook is a hunchback.
Logic bombs can get inside
back doors. There were published bang paths
ten hops long. Designs succumbing
to creeping featuritis are banana problems.
(“I know how to spell banana,
but I don’t know when to stop.”)
Before you reconfigure.
I have worked on my share of complicated projects/products (Tuxedo, the Unix kernel, compilers, proxy servers, application servers, and now in-memory data grids). When I think about creeping featurism in projects, several sources come to mind. Some are worse than others, and some lead to outright complexity:
- Well-intentioned engineers optimising existing features. Combined with the requirement of backward compatibility, this leads to real complexity. Managers should ask themselves whether the extra complexity is worth the cost. If it is, old features should be phased out as quickly as possible and customers migrated to new features.
- Product managers adding features for specific customers. Features should be added in as general a way as possible, not just to maximize return on investment, but to limit product complexity. When features are added for the most demanding customer, managers must keep in mind their broader market.
- Product Managers who add features that attempt to address a new market. Like before, product managers must think about how to do this without making life more difficult for customers who want to accomplish simple tasks.
My biggest bugaboo is the first category. Since most software groups I've worked on comprise a set of talented engineers, their first inclination when thinking about how to improve a product is to either improve an existing feature or add a new one. This is perfectly natural, and we usually call this innovation. Who would say innovation is a bad thing?
Yet we also value simplicity of design and ease of use. Too frequently the nature of the aforementioned "innovation" is at the expense of these two values.
We do have at least one mechanism to encourage innovation while limiting complexity and ease of use: Prototypes. Because prototypes are meant to be thrown away, they can be evaluated before inclusion in a product. Only when the prototype meets all goals, including ease of use and simplified design, should the feature be made part of the product.
Furthermore, building a prototype allows cooler heads to prevail; a feature that seemed vitally important six months ago may be unnecessary today.
I have an analogy I like to use for this. In sticking with the banana theme, I'll call it my Banana Cream Pie Theory. After a filling meal, it is never wise to order a Banana Cream Pie. But if you do, it is better to throw it away than eat it.
Great Post! I agree very strongly. Just by slowly accreting features, very good products can turn into large amorphous blobs that nobody can understand.
I also think that backward compatibility is overvalued and lead to horrendous internal complexity and can completely hamstring progress.
Posted by: David Guy | 05/11/2009 at 08:00 AM