I’ve been sweating bullets with this project I’ve been working on with Neely — he’s supposed to be demoing it at a major conference in New York with a partner in a couple of weeks. But I am still not quite where I’d like to be in terms of polish and grace.
Neely’s been telling me to just code for the immediate requirements and nothing more. But my philosophy has always been to look ahead just a little more and prepare for what’s to come as “no-brainer” feature requests. Apparently this type of thinking has been hurting my development time on this project…
I rarely read Wil Shipley’s blog entries because they are usually quite long and sometimes very technical. But just out of the blue I decided to read “something” today. And there I came across his coding strategy and philosophy on coding for only what’s necessary and nothing more.
I’ve always understood the idea of “push it out to the market first and fix it later”… But I just never felt right implementing that in good conscience knowing that I am purposely releasing a faulty software only to fix it when complaints flood in. But the way Wil explained it made a lot of sense to me and I think I am going to make what he says in that article my focus from now on — if there ain’t complaints, it ain’t broke. And if there ain’t requests, it ain’t a useful feature.
Live and learn…