Hi, I'm Jess. I use Python to craft web apps and sift data. I'm honing my full-stack development chops on Author Alcove.
I’ve been practicing this approach for about ten years now — looking first at the hardest-case scenarios for clients, then after jotting them down, giving a rough outline of difficulty without actually going into nitty-gritty detail.
I have to tell ya, it hasn’t worked out as well as I thought. My clients like to joke that every time I say something will take a lot of thought, it seems to them like all I had to do was think about it a little and the solution magically appeared. Like, the less detail I gave them over time about the specific problems, the more they assumed the job was automatic; to the point that when there was a problem, they couldn’t understand where it was coming from.
You’re trying to convince whining coders to stop dropping their problems into the client’s lap, and I think that’s fair. At the same time, there’s a drawback to setting your clients’ expectations unreasonably high by never mentioning what it took to do something.
My solution, as it’s been, has been to estimate and gauge the scope of the problems and give a non-technical outline before starting the work, and then as I learned the hard way, to make sure I pound the client with all kinds of gruesome technical details about how hard it was after the work is done. That way at least they know what they spent their money on. Otherwise we really run the risk of being taken for granted.
Absolutely, there is a fine line between over-burdening clients with technical detail and not telling them enough about the work so that they don’t really understand what they are paying for. This is something that I still struggle with. And it’s one reason why I prefer working with clients who are fairly technical – they have a better understanding of the challenges involved in a project without me having to do as much explaining.
I think there is a big difference between dropping problems in a client’s lap, and coming to them later with a list of problems plus possible solutions to them all. It is almost always better not to mention a bunch of problems unless you already have some ideas for solving them. Or if it is something that can be resolved without the client’s input, that is even better. Although as you say, it is a good idea to bring it up later so the client knows what they are paying for.
When producing production code, I’m always thinking that the implementation is not-conservative-enough. I guess that is what you means in the article.
Very well stated. I agree wholeheartedly… the amount of times I’ve seen systems crash because a whole load of bits of code which, by themselves, should work perfectly, don’t when they’re all stuck together is mindblowing. Just a little intelligence and a few extra checks and error handlers would’ve saved the day… but no: the programmers were too optimistic, and guess what: they were wrong.
Many of bug born from programmer carelesness such as lack in validation.
OMG, this is so true. thank you for posting this article :)
This has been very insightful, programming is about solving problems thus being a paranoid and a pessimist are fantastic qualities.
Lol’d at the Swallow those words line, I guess ambition and imagination are for artists not programmers…
Notify me of follow-up comments by email.
Notify me of new posts by email.
Browse the article archives.
You can have new articles delivered to your inbox.
© 2007-2015 GrokCode