It often amazes me how much of a problem the "feature creep" phenomenon can be. I am a sucker for bells and whistles, especially when it comes to adding them to what I am working on. The allure of adding on just one more thing because "I am already in this code and it shouldn't take too long and the result will be cool" is strong. Like most computer science students, I read the Mythical Man Month and the whole idea of feature creep was hammered into my skull. It makes sense when discussing a team struggling to meet deadlines; of course you have to abandon pet feature ideas in order to fulfill your end of the contract. However, we were never given much guidance on avoiding feature creep when you are the one in control of deadlines and the product.

I've often seen this problem discussed by solo game developers. Like most things, a game rarely starts out as a fully formed idea. There is generally no end goal that "when the game works like this, it is done". Games and all other interesting creations start with an idea which eventually becomes some concrete entity. On the road between idea and finished game are a series of stops where the developer has to ask "What next?". New features insert themselves into the game with ease, since it is not well-defined. Before anyone catches on, the game becomes an abomination of 36 different mechanics that do not work well together, resulting in a lackluster final product.

Much like physical minimalism, only introduce new "things" when they serve a direct purpose. The mug holds coffee and is used every day; the database stores all of our information and is accessed every time a user logs in. Introducing extraneous and unneeded features will have an exponential negative affect on your project, and can ultimately overshadow the core value.

Creating something is just as much about saying yes to ideas as it is to saying no; in fact, creating is about saying no more than saying yes.