Feature Gathering

There is an important lesson to be learned from the jQuery versus PrototypeJS battle. While there isn’t really anything wrong with Prototype, jQuery is simply better. Yes, there are some pros and cons to either one, but to me, jQuery was simply better designed. It’s as if, one day, some guy decided to come up with a JavaScript framework to make working with JavaScript a lot faster and easier. That person went out, figured out what the day-to-day of JS developers were, and decided to come up a framework based on that.  While I can easily write an article on PrototypeJS versus jQuery, today’s article is on the importance of feature gathering.

Feature gathering is the process of consulting your clients about their needs and desires before creating your application. I’ve come across a few programs where they’ve developed what they thought the client would like, instead of directly consulting the clients about their exact requirements. There are pros and cons of each method. The con, your client might be annoyed with your lack of initiative. The pro, work flow can be streamlined, the code can be designed around how features might be added, main ability, scalability, and etc. I like doing things, and I like doing things right from the get-go. Of course, if I was a developer who wanted a ton of project time, then I’d develop the most inefficient most unmaintainable system there is to get all the money I can, but I don’t. So I rather create a solid, efficient, and easy to maintain product, and that can only be accomplished if I did a good job at the feature gathering stage.