标签: COBOL

In 1981, two colleagues and I set up the first computer-aided software engineering company with the goal of improving the workflow for IBM mainframe programmers. The opportunity was huge, as were the potential payoffs for us and our prospective customers. The original idea was to develop a series of programming tools in a staged fashion. The ultimate goal was to offer a workstation that provided a closely integrated editor, syntax checker, compiler, and runtime emulation of the behaviour of the IBM mainframe's COBOL environment, coupled with testing tools and full code analysis. The plan was to develop the editor and syntax checker quickly and put them into the customers' hands for feedback. Enter the venture capitalists, who required changes in the development plans. These investors (who dominated our board) insisted that, rather than offering the editor/syntax checker initially as a minimal functional product, we offer only the fully capable, final visionary product. To get the funding, we caved. We gave up the ability to get early feedback for our approach. This single decision significantly stepped up the risk factor. We increased the amount of software that needed to be completed, delayed customer feedback, increased the company spend rate, and suffered the usual delays in delivering a working product. Furthermore, we had to scale up our training staff, documentation staff, and field applications engineering staff. The company eventually failed for a variety of reasons, but the chief cause was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design of experiments), we delayed validating our product ideas. Every validation delay increases risk—disproportionately. Apart from development delays, the single largest product failure was rooted in the original minimal functional product. We had planned a tightly integrated editor-syntax checker. However, we had chosen a more capable editor than the one IBM COBOL programmers used. We selected a better but wrong editor. If the original development and release plan had been followed, we would have discovered the magnitude of that single error within the first year of our existence. Instead, we learned of the error more than two years into the development. I've seen and experienced this general sequence many times in my career. I've taken away one fundamental guiding principle: Design the product so that early testing of a minimal functional product (also called an essential product) can begin early in the development cycle. This is a risk containment and control strategy. You'll see this technique used in agile development methodology, Alex Osterwalder's Canvas business generation system, and other enlightened business and product planning approaches. I've adopted a personal approach to product development that focuses on risk mitigation. You cannot and should not eliminate risk. But you should want to contain the effects of risk and control how you react to problems as they emerge. That business philosophy, practised for close to 30 years, is codified by Osterwalder in his book Business Model Generation and by Ash Maurya in his Lean Stack system. The bottom line is that you shouldn't fall in love so hard with the product or company idea that you can't (or won't) see the risks, along with the opportunities to mitigate those risks. In my previous column , I posed the following trivia question: "What 1957 movie was used to influence people subliminally to buy popcorn and drink Coca-Cola?" The answer was a 1957 showing of the 1955 movie Picnic . The experiment failed. James Vicary, who designed the experiment, admitted that he lied about the results. Nevertheless, the effectiveness of subliminal advertising is still widely accepted by the public. Here's another trivia question for you. Long-distance telephone calls used to be measured in minutes. How much did the first three minutes of a call between New York and London cost in 1927? Henry Davis Independent Contractor

In 1981, two colleagues and I founded the first computer-aided software engineering company aimed at improving the workflow for IBM mainframe programmers. The opportunity was huge, as were the potential payoffs for us and our prospective customers. The original idea was to develop a series of programming tools in a staged fashion. The ultimate goal was to offer a workstation that provided a closely integrated editor, syntax checker, compiler, and runtime emulation of the behaviour of the IBM mainframe's COBOL environment, coupled with testing tools and full code analysis. The plan was to develop the editor and syntax checker quickly and put them into the customers' hands for feedback. Enter the venture capitalists, who required changes in the development plans. These investors (who dominated our board) insisted that, rather than offering the editor/syntax checker initially as a minimal functional product, we offer only the fully capable, final visionary product. To get the funding, we caved. We gave up the ability to get early feedback for our approach. This single decision significantly stepped up the risk factor. We increased the amount of software that needed to be completed, delayed customer feedback, increased the company spend rate, and suffered the usual delays in delivering a working product. Furthermore, we had to scale up our training staff, documentation staff, and field applications engineering staff. The company eventually failed for a variety of reasons, but the chief cause was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design of experiments), we delayed validating our product ideas. Every validation delay increases risk—disproportionately. Apart from development delays, the single largest product failure was rooted in the original minimal functional product. We had planned a tightly integrated editor-syntax checker. However, we had chosen a more capable editor than the one IBM COBOL programmers used. We selected a better but wrong editor. If the original development and release plan had been followed, we would have discovered the magnitude of that single error within the first year of our existence. Instead, we learned of the error more than two years into the development. I've seen and experienced this general sequence many times in my career. I've taken away one fundamental guiding principle: Design the product so that early testing of a minimal functional product (also called an essential product) can begin early in the development cycle. This is a risk containment and control strategy. You'll see this technique used in agile development methodology, Alex Osterwalder's Canvas business generation system, and other enlightened business and product planning approaches. I've adopted a personal approach to product development that focuses on risk mitigation. You cannot and should not eliminate risk. But you should want to contain the effects of risk and control how you react to problems as they emerge. That business philosophy, practised for close to 30 years, is codified by Osterwalder in his book Business Model Generation and by Ash Maurya in his Lean Stack system. The bottom line is that you shouldn't fall in love so hard with the product or company idea that you can't (or won't) see the risks, along with the opportunities to mitigate those risks. In my previous column , I posed the following trivia question: "What 1957 movie was used to influence people subliminally to buy popcorn and drink Coca-Cola?" The answer was a 1957 showing of the 1955 movie Picnic . The experiment failed. James Vicary, who designed the experiment, admitted that he lied about the results. Nevertheless, the effectiveness of subliminal advertising is still widely accepted by the public. Here's another trivia question for you. Long-distance telephone calls used to be measured in minutes. How much did the first three minutes of a call between New York and London cost in 1927? Henry Davis Independent Contractor