Wednesday, April 20, 2005


Enron Broadband Trial Kicks Off

There's a bit of a worrying development in the ongoing saga of the Federal Government's attempts to prosecute people for various shenanigans at Enron.

Over at the Houston Chronicle the fragrant Mary Flood reports how bosses at Enron Broadband Services (EBS) allegedly exaggerated the capabilities of their network and software.

Well, as someone who was heavily involved in the Internet boom and bust, in my opinion, this development should cause a lot of tech company bosses sleepless nights.

If the Justice Department managed to convict every tech executive who extolled the virtues of an unfinished (or not even started) product he knew nothing about, claiming it would reduce time to market, revolutionize the industry, convert base metals into gold, etc., etc., they would soon start to outnumber gang members in the Federal Prison system.

If you've ever worked in a tech consulting firm or in software sales, you'll know what I'm talking about.

For example, in the late 1990s I worked in the Insurance practice area of a large consulting firm. Now, the big problem confronting all consulting company bosses is that they lack of a unique selling proposition (USP). In an area like tech - where the technologies have all become interoperable and well understood (at least compared to the situation pre-1990) - the only thing that distinguishes one consulting firm from another is the quality of the business contacts of the senior management.

A few rungs down the management ladder, consulting firm executives look enviously at software firms selling products. They look at the license revenue from sales of software products and - not knowing anything about developing, selling and supporting software products - think it represents free money. And of course they are always looking for that elusive USP.

In this particular company, management decided to build a component-based software development environment which would enable, they thought, more rapid application development, and also open up a stream of license revenue (I don't know why they thought a client would pay for the development platform, but customers are even more ignorant about technology than consulting firm bosses)

So they poached a hotshot young guy from one of their clients who looked great in a white shirt and bouffant hair-do as he wrote a bunch of diagrams on a whiteboard. The premise of this tool was that if you look at what a program actually does, in theory, you can compartmentalise into three logical layers: screen, business rules, and database.

The plan was to build a tool where the behaviour of the interactions between the three layers could be defined and stored as metadata. It would be so simple that customers could paint their own screens! In their haste to bring this wonderful tool which we'll call "PHB" to market, they overlooked two key points:

1. Although you can define what a program does conceptually on a whiteboard, the process of realising any design on an actual computer reveals many unanticipated subtleties

2. If drag and drop metaprogramming was really possible, Microsoft would be there already

If management had thought to consult somebody who had previously successfully delivered a working piece of software to a customer and been paid for it, that person would no doubt have brought point number 1 to their attention. This being a consulting firm, however, I can only surmise that at the time this stuff was under development, they didn't actually employ anybody fitting that description.

So a bunch of contractors were brought in to build this tool. After about a year I was hired on and the tool was demonstrated to me. The first thing I noticed was that both the designtime and the runtime were very slow for C++ applications. After a few minutes research I discovered the cause. "It's all compiled in Debug mode!" I pointed out to the division's chief architect. "Yes, if you compile it in release mode, it crashes!". I started to realise all might not be well. "It needs debugging, then", I pointed out. Unfortunately the contractors who built it had by then all gone. I shouldn't worry, pointed out the architect, when he'd worked at a major European airline, all _their_ production C++ applications had been deployed in debug mode.

They'd now spent about a million pounds building a slow, buggy and practically useless development environment which merely served to cripple developers who could otherwise use the marvellously productive tools like VB (which Microsoft's experts had invested ten years and billions of dollars developing).

Nevertheless, pressure started to come down from on high that they'd better use this thing, and fast.

Management attention turned to another product (which we'll call the front office app) which was being built from scratch in VB. It was virtually finished, and was a robust and functional app, built by a small team of employees and contractors who knew what they were doing. Everybody was in an acquisition frenzy around this time and as part of this the company had recently bought a software house which offered a package we'll call the back office app. Management decided that we would build a new version of the front office application to integrate with the back office application and also change the entire thing to use the PHB tool at the same time as creating a new integrated data model. Perfect!

In a meeting sometime afterward, this momentous decision was explained to me by the divisional manager, who then asked, "why is morale on that team so low?"

Meanwhile, back on Planet Earth, the team had given up trying to get PHB to work. Instead they began rearchitecting the application to work like a PHB app, but without actually using any of the PHB code. (Nothing like keeping the needs of your customers uppermost in your mind!). At this point I went to work in another area for about a year. When I came back, the integrated front and back office application had been handed over to a team in another division following the latest in a seemingly endless series of reorganizations. That team then spent a further year stripping out all of the PHB code and rebuilding the whole thing from scratch as a straight VB application.

Now, a client came along who had a FoxPro for DOS application which had been written by somebody at this consulting firm about ten years earlier when they were still in the business of delivering technical solutions to actual problems, rather than indulging a fetish for technologically-based masturbation on whiteboards. It was a straightforward case management application which their business used on a daily basis.

"So just get a couple of consultants to rebuild it using VB or ASP, right?"

"No! We need to use the PHB tool. OK, the original one didn't work. So before we start rewriting the case management system, we need to have another go at re-writing PHB. "


"Because we sold the rewrite to the client on the basis they'd be able to modify the screens themselves."

Now here we really do start slipping into another duh-mension. From a naive client's point of view, they wonder at the long delay between their asking for a new box on a form, and the appearance of said box in the production application. As developers, we know that if the box they asked for was for example a currency box on a financials form, the ramifications would be potentially huge. From their point of view they are paying a lot of money and waiting a long time just to add a currency box. But what are management doing selling a tool on this basis?

Fast forward another year. The client has already paid about a million pounds. Unfortunately so much time has been spent on the PHB rewrite that two months before planned go-live they are still only 70% of the way through the functionality, while all that money has been burned. Proving senior management never read Brooks ("Adding more people to a late project makes it later") the team is boosted to a total of 21 consultants. (To redevelop, remember, a straightforward FoxPro/DOS case management system originally written by one man).

By this time I was being slated for not working weekends. Management didn't like it when I told them that if in my opinion the system had any chance at all of an on-time delivery, I'd be happy to work nights and weekends to make it happen. As it was, I told them, the client would never accept the system as it stood because each time the client sat down with the team to look at progress, they discovered more things that the old app did, that the new one did not. As the client would never accept the product in its current form, in my opinion, working overtime - without a clear plan - just hoping against hope everything would turn out right was futile.

Where did I get off having an opinion, they wanted to know.

My response was that I thought as consultants we were supposed to give clients the best advice we could based on our knowledge and experience. I pointed out that I had developed and delivered several large systems to demanding clients which had gone live and been paid for. Who in this room can say the same, I wanted to know.

A month later I moved to another division.

This is the best example I can come up with from my personal experience where clueless management paints a totally unrealistic picture of a product or technology (there are others). Now if the Enron Broadband Services bosses get jailed for this, it sends a very worrying warning shot across the bows of technology managers in America.
Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?