Jason Gorman
6 Ideas That Transformed The Way I Make Software
------------------------------------------------
Day #2- Iterative & Incremental Delivery
This is another of those ideas that seem obvious with hindsight, but in the first couple of years of my career, the majority view really was that we gather the requirements, plan the design, write the code, test the software and then release it - usually on a fixed date we committed to months in advance.
(thread)
Jason Gorman
And it turns out that much - often most - of the value in software isn't in what we planned, but what we LEARNED from what we planned. So we need to LEARN as early and as often as we can. That's where the gold we're panning for usually lies.
The last 30 years I've been doing software development has been characterized by those user feedback loops getting shorter and shorter. In the mid-90s, my teams would tackle a bunch of usage scenarios, getting feedback every couple of weeks.
Jason Gorman
Sounds great, doesn't it? All lovely and simple and predictable (and businesses *loooove* predictable). There's just one small problem: it's bollocks.
Even on what seemed like relatively straightforward systems, when the software was put in front of customers and end users, we'd get an avalanche of feedback about what was wrong with it. So there'd be a frantic phase of change requests and bug fixes to try and get the software into the ballpark of usable.
Jason Gorman
And it wasn't unheard of to be so far out of the ballpark that it ended up being abandoned. Just too much work. Quite often design decisions taken months earlier got baked in by all the code we added since.
That final frantic "stabilisation" phase was typically characterised by very frequent user feedback. Okay, we fixed that bug. Waddaya think? Okay, we moved that column. Waddaya think?
Jason Gorman
It doesn't take a genius to figure out that just maybe we should ask "Waddaya think?" earlier, and more often.
Instead of gathering all the requirements, doing all the design, writing all the code, and then testing *all* of it, it makes much more sense - for a student of risk - to gather *some* of the requirements, do *some* of the design, write *some* of the code, and then test *that* to get user feedback, so we can incorporate what we've LEARNED (in capital letters!) in the next cycle.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.