This app. certainly qualifies in that regard: At the start, we had no idea that it would even work. Two years and a few significant adjustments later, we're still rolling the bones on each iteration.
My part in this interview was to basically tell the story of each stage in the application from a boilerplate format something like this:
- What was the problem we were facing?
- What did we do to address the problem?
- Did it work according to expectation?
- If so, by how much?
- Or if not, by how much?
- What unexpected problems/obstacles (if any) cropped up?
Uhhmmmm, there's no such thing as those kinds of things. I only sit on problems long enough for one of the following to happen:
Option A: I have (at a minimum) a strong gut-level diagnosis plus a plan to verify/disprove that hypothesis.
Option B: No immediate diagnosis is forthcoming, but I know exactly where I'm going to start looking.
Arriving at either option shouldn't take very long. Half an hour, maybe. Basically, experience/instinct kicks in...or it doesn't and my Google-fu skills get a workout.
But that's not really the important part. What's important is choosing to work with clients who understand that freaking out at problems only makes them harder to solve. Not only the problem(s) at hand, but future problems as well.
Sure, freak-outs guarantee that you (as a client) won't hear about a lot of the small problems--at least not the kind that are easily and quietly fixed. Maybe you'll sleep better for that. At least until the less-easily-fixable small problems fester into big ones. All because energy that could have been spent on diagnosis is instead channeled into suppressing the symptoms. (And let's not even count the time wasted on blame-slinging and finger-pointing.) I have no sympathy for a client relationship run on a "no bad news" principle. It's tantamount to only accepting sunny forecasts from the meteorologist. Or buying stocks from perpetually bullish brokers. Die of pneumonia in the poor-house, and who's to blame, really? Exactly.
Yes, I realise that no one likes to report (much less hear about) project line-items slipping a schedule date, or costing more than initially budgeted. Or that off-the-shelf software will require more customisation than advertised. Or that a Zero-day security hole has to be patched and rushed out the door in the middle of a release cycle. Or that Google/Facebook/Bing/Microsoft/Apple/PayPal/Etc. has arbitrarily changed their terms of service. Or that a massive DDOS attack is measurably impacting an app.'s response times. Whatever. Stuff happens. Professionals deal with it.
In lieu of falling into a "no bad news" mindset, here's an alternative. You (again meaning the client) can't insist that there will be no bad news. At least without everybody knowing you're on holiday from Reality.
But you can--within reason--insist on no surprises. Obviously, things like security flaws, third party service failures, etc. aren't always predictable. (Hence, the "within reason" qualifier.) Developers, you can insist on a working in a No Freak-out Zone as the price of landing no surprises. (Pro tip: If you're not sure about the client's commitment to the "no surprises" credo, find a small, no-brainer problem to test the waters. Bring it--and your plan to fix it--to the client in person or over the phone. None of this passive-aggressive end-of-the-week-hoping-they've-already-left email nonsense. Nope. Own it.)
Eliminate the freak-outs, minimise the surprises, and the a lot more of the problems will sort out much sooner. After over a decade in software, I can pretty much promise you that.
