Fog Creek Software
Discussion Board

Removing value through software

Ever work on a software project where the ultimate result was simply to remove value from the company? A great sucking hole that absorbed an unlimited amount of funds until someone pulled the plug? Care to tell us about it?

Mike Gunderloy
Saturday, February 9, 2002

In my case, the one that stands out in memory was a big consulting gig in 1998 and 1999. Salient points:

- Started as a Y2K fix-up job
- Hey, as long as we're touching all the code, let's migrate from COBOL on the mainframe to VB on the PC for the entire system!
- And let's push a new hardware platform that we can't even buy yet (but that our vendors say will be available in plenty of time) out to our drivers for realtime data entry
- No need to hire new developers, we'll just give some of the old guys a VB class and turn 'em loose
- Testers? We don't have a budget for testers, sorry
- And then every month like clockwork, a new round of "Oh, did we remember to mention requirements x, y, and z? No? Oh, well, now you know."

Judging by the costs that I know about, the company put upwards of $10 million into this morass until some smarter person decided to go back and patch up the COBOL after all.

Mike Gunderloy
Saturday, February 9, 2002

Yeah, I once worked an a $1M US debacle that only happenned because it was on a key performance indicator list of a senior manager. He got a bonus because the project was started and underway. Then he left and the project folded.

Sunday, February 10, 2002

I worked on a project that attempted to re-develop a country wide POS application. Management were sold on the use of a "new" middleware technology and they paid heaps for it.  When it was found that it didnt work as expected and that they had to wait 6 months for features they needed to role out into the field, management went into "arse protection" mode and adamently defended their decision to use the "new" middleware.  All a long the technical people suggested (some of them very strongly) that the "new" middleware technology would not cut the mustard, but what did we know.  Of course those same management people still have their jobs, but the 250 staff that were on the project are no longer.  Effectively removing their value through software, or more precisely, the incorrect choice of software and managements in-ability to listen to the technical people.  Those wine and dine sessions must have been awsome to get them to buy the product. At least someone got some value from the software.

James Ladd
Sunday, February 10, 2002

There are bad projects in every company and they are bad for every reason in the book.  Asimov and probably many others said that the trouble with bad ideas is that they never really go away.

The motherload of bad ideas during my career was Re-engineering and I mean big "R" Re-engineering.  I was involved with lots of projects that put folks out of work.  That's the dark side of our profession -- if we are successful in making folks more productive, you don't need so many of them.

But here is how re-engineering ususally worked.  They (the consultants) made a plan.  They defined the cost savings.  They set a deadline:  By this date the new system would be operational and you could remove folks from the payroll.  Well, the Human Resouce folks could always meet the staff reduction deadline.  But ...

Monday, February 11, 2002

A software company I worked for used to "re-invent" itself every couple of months. Basically the same technology was repackaged in some new context (with the appropriate buzzwords attached.) When questioned about this management always stated that it goes to show how nimble we are (BTW, this company is still around and has re-aligned itself yet again.)

While the core technology did survive from one direction shift to the next, lots of infrastructure was built over it that was always getting jettisoned. As a software architect and project leader I was in charge of the designed and development of no less than five user interface products. Some of these actually made it to customers, and two were actually profitable, but ultimately they were always dropped when the paradigm shifted.

It's a bit saddening for me to think about the fact that most of my development over the past five years is rotting away in some backed-up VSS archive. Well, it least I had fun.

Dan Shappir
Monday, February 11, 2002

I was product manager for a web based application.  Our database wasn't cutting it, so we made a plan to replace the back end database and move to a new data model. The original was designed by a very bright guy, but he wasn't a database guru. The new model was much better.

But no one ever told the people on the project to just change the queries, and leave everything else alone.

It basically turned into a "rewrite from scratch" project.  Six weeks turned into 8 months before the beta release and one year before production release.



Bob Crosley
Monday, February 11, 2002

One of Mike's points in the description of his value removal project was:
"- No need to hire new developers, we'll just give some of the old guys a VB class and turn 'em loose"

Was this bad?  Domain knowledge can be quite important on a development project.  It would likely be easier to teach existing developers a new language than to hire new developers with language knowledge and teach them what they are to develop.  Why would this have been a problem on this project?

Gary Chatters
Monday, February 11, 2002

Anybody remember Taligent?  A joint venture between Apple and IBM to develop a new OS, er, uh, a new "Application Environment".  A $250M smoking crater.  IBM later tried to recover some value by hawking the source code on CD for $99.  I think the only buyers were ex-employees who wanted a souvenir.

J. Peterson
Monday, February 11, 2002

Gary, the problem with retraining some of the existing developers on VB was that they took a team of six, gave them three days of training, and then expected them to completely rearchitect a major IT project into the new language. The training wasn't remotely enough for them to understand the ins and outs of the language.

Oddly enough, they didn't really seem to have the domain knowledge either. Every time I went along on a meeting with actual users, things came out that were apparently a complete surprise. "What do you mean the rate depends on all those factors? We thought it was just the distance!"

Mike Gunderloy
Monday, February 11, 2002

Mike, your more detailed description makes it more apparant why there was a problem.

Gary Chatters
Tuesday, February 12, 2002

Businesses have to take some risks if they're going to get ahead.  Some of those projects will fail.  Is there anything special about software only projects?  Do they get bigger or last longer before they're stopped?  Should it have been obvious sooner that the project was going nowhere?

I haven't been associated with any big software only disasters, but did have a very short assignment on the Iridium project.  But that was a whole system with hardware and software.

Maybe I should be careful about saying I haven't been associated with big software disasters.  My previous employer, a B2B software developer is currently about $2.6E+9 in debt and has cut staff down to less than 1000.  But they're still in business, so it may work out in the long run.

Gary Chatters
Tuesday, February 12, 2002

Dan you just made me cry. That sounds so much like my current situation it is unbeliveable.

It does get very depressing working for years on the same project and never having anything to show for

Tuesday, February 12, 2002

*  Recent Topics

*  Fog Creek Home