Thursday, August 6, 2015

On iterative work products

Most of you probably already know this, but here's a so-called secret that writers use when possible - if you write something, try to repurpose it somwhere else.

So I'm going to go back to something that I wrote back in 2010. Back at the time, Red Hat's Jim Whitehurst made some comments about bloated software development cycles.

The main problem, according to Whitehurst, is a commercial development model under which executives, programmers, and marketers get together in an effort to predict what their customers want-and then take five years to build it.

At the time (2010), I weighed in on this, and wondered if iterative cycles could work for everyone.

My initial impression - and please correct me with facts if I'm wrong - is that a more iterative development process works better when your customers are technically savvy, or if the iterations are managed in such a way that the customers are never exposed to them....

But imagine if Microsoft Word were on a more iterative development process, and Microsoft was releasing new versions of Word daily. And let's say that the October 22, 2010 version introduced a new menu item. (Forgive me for my dated references to "menu items," but I use Word 2003 more than I use the later versions of Word.)

What does this mean?

It means that if I walk into a store on November 26 and look at the Word packages available in the store, chances are that I won't know whether the package includes the new menu item or not.

So I go ahead and install it, and I'm asked if I want to get the latest software updates, and I say yes, and the software (and the on-line documentation) is updated. Problem solved?

Well, I need a little more help sometimes, so I go to the Barnes & Noble in Montclair, California (I'm trying to become the mayor, you see) and look at the Microsoft Word books on the shelf. I select the book written by Steven Hodson, which happens to have a publication date of November 2010. What I don't know, however, is that Hodson wrote the book in July, using a beta copy of Word that included some features that made the August 12 release, some that made the August 14 release, and one that was dropped and never released - yet.

After searching in vain for an answer to my menu item question, I do what I should have done in the first place - phone a friend who's more knowledgeable about such things.


Can you tell that I wrote this in 2010? (For one thing, why did people go to these "bookstores" to learn stuff?)

Part of what was going through my head was something that I acknowledged in the 2010 post - I had just completed nearly a decade of product management for a product designed for cops. And the way that I managed the product was to write a marketing requirements document, which was then handed off to people who wrote a technical requirements document, who then handed it off to other people who wrote more detailed documents, and so forth.

Things have changed a bit since 2010.

Now we talk about short stories that evolve as we prepare for short sprints. We're not waiting a year for the next set of features.

And what of the Microsoft Word that I talked about in 2010? Well, that's changed too:

"We have had to change the way we build our software," [Jake] Zborowski says. "Before, we forked our code, packaged in for on-premises, then figured out how to do the changes in the cloud. Now we no longer branch the code – we enhance the live (Office 365) code that people are running on."

As a result of this change, Microsoft has moved from a model of releasing updates once every three or four months to small, incremental updates every day.


So I guess this is another Jim Bakker "I was wrong" moment on my part. I'm getting really good at these.
blog comments powered by Disqus