This is single handedly one of the most dangerous things that can be claimed about software.
The code itself amounts to about 15% of the actual work of building and supporting an application, almost every programmer i care to know can tell you that the DESIGN of the application is the hard part. almost equally as rough is the documentation of the code so that you aren't the only person who knows what the hell it does (this is doubly important in open source projects and something i myself fail badly at most of the time). Documentation of the App itself is another area that gets missed. There is a reason that Apple has armies of people dedicated to documentation, QA, Testing, Design, Layout, Planning, as well as developers to do the actual implementation. Nobody is saying you have to IMPLEMENT everything in 1.0. But you do need to THINK about as much as you can possibly consider up front, and not just dismiss stuff as "that's too big, its a 2.0 feature" or "we'll make that a plugin". Not writing the code, and not considering the problem are two different things. Again, if this was anything more than sterile conjecture, we'd have a Trac, Redmine, or <other> instance set up and would be doing a true roadmap of features, with silo'd debates about each and ultimate with our technical lead, ui lead, beneviolent dictator, etc setting milestones for features. -nick -- Nick Peelman [email protected] "If you're attractive enough on the outside, people will forgive you for being irritating to the core." On Jan 25, 2010, at 23:21, Jack Shedd wrote: > Not necessarily. To get started, the group just needs a rough outline of > possible problem areas. It does not need to have an absolutely perfect > specification document. > > The best products are built was you go. _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
