One of the books that i am reading Microsofts Secrets, It seems pretty interesting and then. It has a lot of sections focussed on development methodologies used within microsoft, while reading this i was remided of a blog by another microsofter, Chris Pratley - he has written a blog on schools of software development, here are some excerpts from the blog....
School 1:
The "wait until its perfect" school. This approach believes that software needs to be "done" before it is released to the public. Done is defined as having all the conceivable useful features, polished to a gleam, and of course "bug-free" (see my previous posts on that fallacy). These products tend to take a really long time to come to market, generally miss their opportunity since someone with a slightly lower standard than "done" has beaten them to the punch and worst of all, they spent so much effort on getting things perfect they forgot to actually try the product out on real people and make sure they weren't missing the boat and adding things no one cared about
School 2:
The "we'll just release a new build" school. This version develops software that sort of works, then sends it out for feedback as version 0.7.1.0145 or whatever. They get some feedback, make changes and make a new build with a slightly higher build number, like 0.7.1.0146. In fact, they make a change and produce an update whenever they hear about a problem. This software usually never actually ships - it just gets slowly better although often only in increments. In fact it may never make a great leap in innovation, since it is constantly in a state of trying to get closer to a specific goal. The response to any problem is simply "we'll just release a new build".
The "ship early, ship often" school. This is the one that most client software that Microsoft makes has followed. The theory goes that if you try to plan too much before you ship your first product (wait until its “perfect”), you will not be able build a truly useful product since you don't really understand who your future users are yet and what they will find appealing in the product. So the best thing is to get something out there, understand what is appealing and what isn't from the “early adopter” feedback, then ship another version that responds to that feedback as soon as you can. Typically, version 2 starts before the feedback from version 1 comes in, so version 2 is usually a polish of the partially misguided version 1, and version 3 is the real re-work to make the product what its prospective customer base really wants.
School 1:
The "wait until its perfect" school. This approach believes that software needs to be "done" before it is released to the public. Done is defined as having all the conceivable useful features, polished to a gleam, and of course "bug-free" (see my previous posts on that fallacy). These products tend to take a really long time to come to market, generally miss their opportunity since someone with a slightly lower standard than "done" has beaten them to the punch and worst of all, they spent so much effort on getting things perfect they forgot to actually try the product out on real people and make sure they weren't missing the boat and adding things no one cared about
School 2:
The "we'll just release a new build" school. This version develops software that sort of works, then sends it out for feedback as version 0.7.1.0145 or whatever. They get some feedback, make changes and make a new build with a slightly higher build number, like 0.7.1.0146. In fact, they make a change and produce an update whenever they hear about a problem. This software usually never actually ships - it just gets slowly better although often only in increments. In fact it may never make a great leap in innovation, since it is constantly in a state of trying to get closer to a specific goal. The response to any problem is simply "we'll just release a new build".
The "ship early, ship often" school. This is the one that most client software that Microsoft makes has followed. The theory goes that if you try to plan too much before you ship your first product (wait until its “perfect”), you will not be able build a truly useful product since you don't really understand who your future users are yet and what they will find appealing in the product. So the best thing is to get something out there, understand what is appealing and what isn't from the “early adopter” feedback, then ship another version that responds to that feedback as soon as you can. Typically, version 2 starts before the feedback from version 1 comes in, so version 2 is usually a polish of the partially misguided version 1, and version 3 is the real re-work to make the product what its prospective customer base really wants.
posted by Prashanth Rai at 12:18 AM
0 Comments:
Post a Comment
<< Home