Earlier in 2000, we signed our biggest deal with Succubus Corp., a major gas utility. Phase I would be implementing existing functionality. VPC had helped as a reference, but I'm guessing it was the wildly optimistic promises, timelines, and budget-friendly price of Phase II that sealed the deal. The thinking was that we might not make any money, but they'd cover the development costs. Then we'd starting making the big bucks, or at least that was the thinking. Weeks earlier, we had an event to celebrate the "merging and e-merging" of our company. We would be joining forces with a virtual company that controlled our IP and was bankrolled by a real estate company. Hedley would leverage the parent company's credit to swing a sublet of Alcoa's former headquarters on the 52nd floor of the second-tallest building downtown. The mayor, who was on hand to say a few words, seemed to be a bit suspicious of our projected revenues of $250 million in just a few years, and paused a moment for a sideways glance as he spoke the numbers. A number of recently bestselling books will attest to the many pitfalls of scaling up even the most successful small companies. But reality was never a significant input to planning decisions, so why should we let it start interfering now?

The Candygram System's current incarnation was able to handle basic customer functions and retail product and services billing. In Phase II, we had agreed to develop a much more sophisticated billing and customer care functionality. We needed to be able to support a wide range of features needed by regulated gas utilities, deregulated retail and commercial energy companies, and gas transportation and pipeline businesses. We were still implementing Phase I, concurrently with the new development. But that wasn't all; we had a few demos for other larger clients that needed some new features, too. This was in addition to our regular load of existing customer support and custom system development.

Recognizing that we were unlikely to start working smarter, doubling or trebling our productivity overnight, a bold plan was hatched: we would work harder, much harder.

The effort rested squarely on the development team as we represented the long poles in this project plan. Training, documentation, and implementation would be, at best, playing catch-up. We had no real specs from which they could coordinate their efforts. We were making it up as we went along. Soon they were struggling just to stay abreast of new functionality spewing forth from development.

Even with the pressure of developing our real product, much effort was spent pulling off one of our most impressive tricks: creating a software equivalent of the Turducken. The Candygram System (technically CS3) developed during the spring was completely unrelated to previous generations of the product. However, one of those previous generations had an implementation of a gas-specific billing module that the new version did not yet have. Apparently noticing they had the same name, ownership suggested that we port the gas-specific module to the new system, and in fact had promised that we would demo exactly that concept at an upcoming trade show. At first, the development team laughed at the idea, but the owner was serious, so we had to find some way for it to work. I'm ashamed to admit that I found a package of Windows API calls that enabled screens from a compiled Windows application to appear as child windows in our new system. With the "hard part" out of the way, all that was left was the not-so-minor issue that the systems were using completely different databases. A few hundred hours of development and data mapping made for a convincing-looking system, albeit one that resulted in no revenue, but the owners were not discouraged.

Their sales claims, and by extension, the company website, became a ripe source of joke material for the development team. A prime example is the following excerpt from an energy industry research firm's 2002 CIS report:

In 2002, the Candygram System was a Windows-based client/server system. The J2EE web-based version of Candygram was christened with the unintentionally dark but hilarious name "Candygram: The Final Solution" by Hedley at our first product planning summit. It remained a joke six years later, as each attempt to ramp up our Java™ efforts was soon scuttled by another development emergency.

The claim that the Candygram System could "manage all forms of energy" still makes me laugh out loud. I can just picture one of the owners at a sales presentation listing all of the forms of energy, à la Bubba in Forrest Gump: "Gas energy, electrical energy, thermal energy, kinetic energy, chemical energy, nuclear energy, rotational energy, potential energy, gravitational energy, nervous energy, sexual energy…" That claim soon had me crafting a host of regular expressions to transmute our core gas module's VB and SQL code into whatever energy market was targeted that week.

But we still had hope, and all the "fun" things about the office and our group were now amplified by 80+ hour work weeks. Running jokes no longer had an evening or weekend to fade. They were handed off from shift to shift, becoming more twisted with each iteration and compounded by weeks of accumulated sleep deprivation.

We not only worked hard, we played hard. We parlayed the end-of-Blitz event into a company-funded party at my house to coincide with the AFC/NFC championship games. We had gourmet food from all across the Internet, enough top-shelf booze to kill W. C. Fields, with the guest of honor being a 15 lb. USDA prime rib roast, flown in from Chicago.

The celebration turned out to be a bit premature. Against the odds, we met our customer's deadline, or so we thought. What we didn't realize is that while we were toiling away, the customer was also busy moving the goalposts.