

A better software development process - swhnorton

I recently joined a growing company that, among other things, builds web applications.  <p>The development process boils down to:<p>1) Determining Requirements<p>2)Building exact specifications complete with descriptions of functionality and mockups<p>3) Developing the software to match the specifications<p>4) Creating a QA test plan to break the SW and ensure that it matches the specification exactly<p>5)making necessary changes to both the specification and software<p>6)Rolling out the product to users<p>Being a loather of redundancy and having a personal project/startup background, this process strikes me as antiquated and arcane.  Surely there must be a better way to develop software.  What are some of the workflows that work for you to create great features when you've got more than just a couple people hacking?  What can startups teach scaling companies in this light?

======
willarson
I agree that seems kind of stiff, especially for a smaller company that is
developing for the web. Getting Real is a quick (and free to read online) book
by 37signals that helps focus on a very light development process
<http://getreal.37signals.com/> . Reading it might give you some material for
suggesting ways to improve your company's workflow (and coming from a fairly
credible source).

Many web startups have come to resemble the open source development pattern:
release early, release often, don't plan too far into the future (your
assumptions will probably change by then). I think these are all good ideas:
you get feedback sooner from real users, which allows you to focus on
providing functionality that your users actually want (or at least think they
want).

In general I think the extreme programming propaganda has a lot of good
advice, but I don't know if any large companies have successfully applied them
to teams of more than 10-20 people.

