Hey Guys — I agree with alanchrishuges, I have been keeping tabs on v.0.1.9 since December and it does appear that this is a classic case of “feature creep” taking over.
I am not an engineer so unfortunately I am unable to jump in and lend a hand, but I have been around a lot of software and web product development in my days and have learned that “Defining Scope” and sticking to it has a ton of value in the development process.
The *process* is valuable because if forces you to address potential conflicts and rough spots in the product while the whole thing is still hypothetical. Identifying what can be tackled now in a particular version and what will have to wait until v.2.
Defining scope is valuable because it gives the entire team a reference point for all the work to be done throughout the project and a common language for talking about the work. Defining your requirements drives ambiguity out of the development process.
I have seen many web applications in development that seemed to be in a state of perpetual beta: almost, but not quite ready for to roll out to actual users. The big stumbling block was an unwillingness to document requirements. It is a lot of hassle to write everything down but it makes the difference between launching a set of features the everyone gets start to work with or never launching any.
What this looks like from the inside of an organization is an ever-changing mishmash of features in various stages of completeness. Every new article somebody reads or new thought that comes along while someone is playing with the product inspires another feature that gets considered. This results in a constant flow of work, but with no schedule, no milestones, and no end in sight, and since no one knows the scope of the project, how can anyone know when the product is done.
There are two main reasons to go to the trouble of documenting requirements
Reason #1: So You Know What You’re Building
If you write down a description of exactly what you’re setting out to build, everyone will know what the project’s goals are and when they’ve been reached. It becomes something that is concrete that everyone at every level of the organization from top to bottom can work with. Having a defined set of requirements allows you to parcel out responsibility for the work more efficiently. Seeing the entire scope mapped out enables you to see connections between individual requirements that might not otherwise be apparent.
Reason #2: So You Know What You’re Not Building
Lots of features sound like good ideas, but they don’t necessarily align with the strategic objectives of the project. Additionally, all sorts of possibilities for features will emerge after the project is well underway. Having documented requirements provides you with a framework for evaluating those ideas as they come along.
Knowing what you’re *not building* also means knowing what you’re not building *right now*. The real value in collecting all those great ideas comes from finding appropriate ways to fit them into your long-term plans. By establishing concrete sets of development requirements and stockpiling any requests that don’t fit those requirements as possibilities for future releases, you can manage the entire process in a more deliberate and conscious way. And if you don’t consciously manage your requirements, you will get caught in the dreaded “feature creep”
I commend you all on the work that you’re doing, I am very excited to be able to get my hands on a copy of what your building. I don’t know about everyone else, but I am willing to take a smaller feature set sooner than have to wait for it *all* to be complete.
Kindly and thanks!
Albin
