[wdm_image_effects effect=”no_effect” animation=”slideInUp” shape=”no_shape” color=”#000″ social=”” title=”Plan-a-b-c” description=”Plan-a-b-c” id=”3044″ show=”hover” counter=”0″ size=”medium”/]
You can take this headline as a rule, not an exception. You’ll recognize the truism, “No battle plan ever survives contact with the enemy” first stated by German Field Marshall von Moltke way back in the 19th century.
Our variant of the “battle plan” truism is important to internalize. A product at the concept stage contains feature-functionality that customers may not want or be willing to pay for, or which just might not work well enough for release to the public.
Plan for change; sometimes at the last minute. Allow for the cost and extra time for tweaks to the product or service. Make the first release a limited, controlled one, so that changes and corrections can be made much more easily than if a general release all at once.
You may recall that Microsoft planned a new file system for Vista, but pulled the file system from the product before release, and has not released the WinFS file system yet as of this writing, years later. It is interesting to note that not many of us even remember this “feature” let alone miss it.
And how do we protect ourselves against surprises that relate to feature-functionality as opposed to product quality upon release? Early contact exposing friendly close customers to the product are critical to the development staff, marketing and even to the customer that feels closer to your enterprise because of the special treatment. This is not to state that the customer tests a new product before we do internally, although many of us are surely guilty of that error.
[Email readers, continue here…] Back when I was developing early systems for the hotel industry, with the full cooperation of the owner and managers of a hotel in Tulsa, Oklahoma, I would fly in from Los Angeles on Friday evenings, install new releases that night and make fixes on the fly in a real 24-hour environment. Sunday afternoon, just about departure time for my scheduled flight, the hotel manager would drive me to the airport barely in time to make the returning flight.
My excitement in having developed so many new and “somewhat tested” features over a sleepless weekend was exceeded only by the enthusiasm of the entire hotel staff for the new and wonderful capabilities left behind after the magic weekend of non-stop programming. These trips were so common and their aftermath so predictable (a late-night emergency repair call waiting for me at home upon return Sunday evening) that the hotel owner created a mantra that stuck with me and caused quite a laugh at my expense for years. He would be sure to remind his staff, shaking my hand goodbye as I left in a hurry to catch that Sunday evening flight: “Wheels up, system down.”
I am not advocating such brazen behavior today. “Cowboy coding” is no longer common or permissible in the computer software industry, especially for enterprise systems. But those were the days.
