Fog Creek Software
Discussion Board




I have a confession to make.

After all the sermons I've given to people about good software engineering practices, about raising the standard in our industry, about ensuring your design is solid and more importantly about using a testing framework to routintely test your software....I just blew it big time.

I made a number of changes to some code, didn't really think them through all the way and worse yet, didn't test them adequately....and then went to a meeting to demo my system and watched it fail in a most spectacular way.

I wonder if this ever happens to Steve McConnell?

Mark Hoffman
Thursday, March 13, 2003

Ouch.  Sorry to hear this.

It happens to the best, though.  I hope the meeting attendees were able to pretty much laugh it off?

(This illustrates the benefit of automating things so that, for example, you *can't* compile without having already built tests.)

Brent P. Newhall
Thursday, March 13, 2003

It's always easier said than done,...

Prakash S
Thursday, March 13, 2003

If it helps, it probably happened to Steve McConnell so many times he resolved to change his ways for good and write a damn book about it or something ;-)

Robert Moir
Thursday, March 13, 2003

Never happened to me. I always do the right thing.

yeah right....

remember - "to err is human".

Alberto
Thursday, March 13, 2003

To err is human, but to really screw things up you need a computer.

Anonymous Coward
Thursday, March 13, 2003

Look at it this way - you will never make that mistake again! (You won't, right?)


Friday, March 14, 2003

I find demos are very nerve-wracking.  I've tested, double-checked the code, tested, got colleagues to use the system, tested, etc...
In the demo - 'this is the system, click on the button xxx to use feature xxx <wince> and as you see it does what you asked of it. <whew>' etc
At the end, the sense of relief...

ScottB
Friday, March 14, 2003

The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila

Mike
Friday, March 14, 2003

Thing with demos is that they almost always happen in unusual circumstances (Running all the servers of a laptop that goes into sleepmode right in the middle of things, disconnected from the DNS servers with no LMHosts file entries, switching to a second monitor so you can keep Powerpoint going on the first screen, ...), that are often ouside of the platforms target constraints.

Always prepare for a demo failing in the most horrible way.
(easier said than done, I know).

Just me (Sir to you)
Friday, March 14, 2003

I have some superb demos I'd like to do, but since they'd all involve "real" comms using a phone line I just don't dare!

Peter Ibbotson
Friday, March 14, 2003

reminds me of the Windows 98 demo by Bill Gates - that was hilarious :-)

Prakash S
Friday, March 14, 2003

This is why I think most demos should be 'Smoke & Mirrors' until the app is ready for production/release because I don't like explaining (excuse-making) that 'Well we're still working on it.'

GiorgioG
Friday, March 14, 2003

Speaking of demos:  I once read an article of advice by former engineers at Be, Inc. about giving demos (Be demos regularly amazed audiences).  One suggestion was to always use the exact same computer to demo as you had to practice on.  In other words, change NOTHING between practice sessions and the demo.

Brent P. Newhall
Friday, March 14, 2003

Brent,

That only works if you're doing the demo at your site unless you've got alot of $ to spend on beefy laptops. 
Terminal Server/Remote Access, etc is no good because you can't depend on the client giving you internet access at their site, not to mention firewalls, etc. 

Boss had to do a demo at a big client's site and the only access they give you is through port 80.  Problem is we were going to use VPN to get into another client's office (with their permission) to demo something we had done for them.  In the end, I put RemotelyAnywhere (remote access over http s/w) on my home machine (cable modem), set it to run on port 80, setup the VPN client to our other customer and ran it that way.  Needless to say it was dogsh*t slow and we wound up bringing these folks into our office 2 months later to do a real demo.

GiorgioG
Friday, March 14, 2003

I believe bringing your own machines is a must.  Unless you're trying to score a hail mary by installing it in front of them.  PCs are too variable in too many ways.

Other reasons are that you care a lot about security and you want to be considerate to your clients' machines

Tj
Friday, March 14, 2003

Oh I wished I could blame the problems on differences in the computers, but this is an web-based intranet application that runs from a single server.

Mark Hoffman
Friday, March 14, 2003

No one's perfect.  Not even Steve McConnell.

HeyMacarana
Friday, March 14, 2003

Well, were you forced by management to make those changes? :)  What kind of time pressure were you under?

I regularly do demos at work.  No matter how large or small, we always seem to wind up making ridiculous and invasive changes at the last minute, after we pledge to freeze the code at a given point.

Generally, we manage to avoid blow-ups, but at the very least, these last-minute changes lead to making our software quite unmanageable after a number of demos.  Thus, we then spend a lot of time refactoring between demos.  Quite the vicious cycle, that--we make huge messes for demos, and then clean them up in the interim. :)

I'm not trying to make this a soapbox for ranting about my job, but just giving an example of a general point.  Demos are pretty much the antithesis of good software management processes, because they often carry with them the time pressure and the anxiety that avert the creation of great software.

That's not to say one should never give demos, but they should be few and far between, and with much aforethought.

(the worst, by the way, is when you're in the "Surprise!  We have a demo in 5 minutes!" situation--never has my life flashed before my eyes quite so quickly...)

smkr4
Saturday, March 15, 2003

"The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila "

Comedy GOLD!

In all seriousness - I doubt there is a coder amongst us who has not, for one reason or another, at one time or another, blown it big-time on a simple piece of functionality and ended up kicking himself.

It goes with the territory.  The trick is not to avoid mistakes, but to make as few as possible and avoid making the same mistakes more than once.  If you can do that you're in pretty good shape.

Norrick
Saturday, March 15, 2003

You should be fired.  You NEVER make a change to production level code without proper change control approval in place. 

Bella
Sunday, March 16, 2003

Who said "production level code"?

Practical Geezer
Monday, March 17, 2003

At my last company, we had a demo product that was kept on a completely different baseline than our production baseline.  It was even developed in a completely different language, Visual Basic instead of Java.

This was not to be deceitful; I saw it in action, and it worked just like our present application (except for a few future features simulated).  But it was easy to rig up a demo in VB that only used hard-coded data (or screenshots, in some cases), which could run as a stand-alone application.

This meant that management *couldn't* screw up the production app by requesting a feature at the last minute before a presentation; they'd simply screw up the demo app.

Brent P. Newhall
Monday, March 17, 2003

*  Recent Topics

*  Fog Creek Home