that sucked
A great deal of discussion at technology conferences involves success - what's the next big thing, how great and smart we all are, and so on. So for a while I've wanted to start to discuss the opposite and explore the lessons of failure, as I suspect that when some project succeeds, it's hard to identify exactly what made it happen, but when something goes wrong, it's pretty obvious.
Over the few years I've built a number of things, some of which succeeded spectacularly, a few of which did ok, and many that sank directly under the waves without making so much as a splash. I like to pretend that I've learned a thing or two from those failures.
So at this year's Foo Camp, I ran a session called "That Sucked" which allowed people to bring up some hairy problem they had, and how they solved it. As we went through various problems I tried to identify the true source of blame and note it on the board. Not to anyone's suprise, a great deal of angst centered around databases and encoding (especially Unicode). An especially painful story from David Heinmeier Hansson about both had everyone nodding in comisery, and Paul Graham recounted his first encounter with printf debugging.
After the session, a number of people approached me to talk about things they were too embarassed to bring up in group, many of which which were even better. I would love to see an entire meeting about this stuff, as it seems like lots of painful lessons could be applied to all. But barring that -- anyone got any particularly good stories?
Comments
A meeting, as in "SuckCamp"?
A story, as penance for the above: Back when I was employed as a consultant, I was on a project for a little while whose success hinged on solving the Halting Problem. But wait, there's more!
This particular project involved solving the Halting Problem in order to divine the intent of the page layout engine and PostScript generator in a major page layout application. Why? To do properly-formatted mail merge rather than do it in anything resembling a sensible manner (say, via one of the many commercial packages that were available for doing just that).
The direct cause of the project's failure was an executive without sufficient technical expertise who sold a client an overly-specific solution (we'll do this particular thing in this particular way), and then dictated both the solution and the timeframe for delivery to those actually doing the work...
- Chris Hanson
Ah! I remember once somebody's code kept knocking down a trading engine server again and again. Turned out someone had written a regexp that ran forever. When we yelled at the offender, he muttered that computers ought to determine when they are about to run a function that never terminates, and then not do so.
Details are hazy, but I believe someone beat him senseless with a copy of Knuth.
- joshua
how about spending 4 days trying to figure out why some special TIFF rendering widget your team purchased to display weird medical images isn't...well, displaying, only to figure out that it was but was rendering itself a pixel by a pixel. no image accessible.
never was able to sweep that one fully under the rug ;)
- stephen o'grady
As an old geezer, where do I start...
- Anything regarding Symbolics Machines (Alt-Meta-Hyper-Super) - Solution: End of Summer Internship, Obsolescence.
- LEX and YAKK - Legend says no one can EVER get correct results from LEX and YAKK on the first try, even after worked years with it. -Solution: Perl
But the most colossal problems I faced were based on using the WRONG tool for the WRONG job.
Example: In a company not to be named, some genius had the idea of using Galaxy as a cross-portable software solution to move fairly sophisticated code from Suns to the Mac. Same genius proposed Macs on the trading floor.
Too bad 50% of the functionality was not available on the Macs...
Solution: Quit, Trading floor revolt followed by mass IT firings. Macs never made it to the floor.
- RobH