minimalist design choice: pt 2
writing x programming, sans x
I have written previous about the horrors of feature creep, but there’s also another side to that coin. What about totally valid, useful, and awesome requests? Let’s assume you have a project that you’ve been working on for a good length of time. It’s working, there’s no major issues, and you’ve released it into testing. After some time, reviews from people start to come back to you. Nobody has yelled at you for it exploding their computer, ruining everything good in the world, or even crashing with no apparent reason. All in all, you’ve put this one down in the books as a success.
And then, it happens. Someone comes in with a feature request. “Hey man! It’s great exactly like it is, but you know what would make it just that much better? <insert foobar request here>.” The thing that makes this different than the previously discussed feature creep is that you agree with them. You think about it, and unlike the normal user request which you’d normally respond to with “NO! I hate you and everything about you and if you want that feature go install <similar program that does what they want already>!” they’re making a request for something that you actually think could be a good idea. Now what?
Well, I can only speak for how I do it. I’ll set a restriction on the project’s development. “Sure,” I’ll say while smirking ironically at the mailing-list, bbs, irc, or whatever I’m seeing this request on…which is useless because the person on the other end can’t see the smirk, “I’ll do it, but it’s not going into the master branch unless I can meet <insanely low sloc count || extremely low resource limit || whatever your initial design consisted of>.” Now you’ve challenged yourself to not only add something that you think is worth doing without breaking the existing functionality, but you’ve made sure that your original ideas are not being deviated from. Making a program change is easy, but by setting these limits on yourself, you force your creative spirit to go to work so that you’re doing it in a simple and elegant manner.
While this may sound like corner-cutting, it’s actually the very opposite. It’s like insisting that a heavy weight be lifted with only one arm. It may not really matter that much to the end user, but it does improve your strength as a programmer/designer. It’s been said that a smooth sea does not make a skillful sailor, but then there are those guys who do whitewater kayaking. They pick the hard path because it’s hard. By constantly challenging yourself to do more with less, you’re more readily able to make simple and clean changes that do what you want them to without having drastic side-effects.
I would go so far as to apply this to the user as well as the designers. Those users who use command line over a graphical file manager are normally much more comfortable in different environments. It’s harder to throw their “groove” off. If someone asked how to best learn cli, I would be upfront about it:
“The fastest way to learn something new is to limit yourself to using only it.”
By not booting into your graphical environment, you’re far more likely to learn how to get along without it. By not allowing yourself to go nuts, your programming will end up less complex.