At work I came across a piece of fine software (fine as the ‘F’ in RTFM) to access the data from an open-source project that decided to throw a warning dialog box every time when it come across some minor data integrity issues while going through tens of thousands of entries.

Upon inspecting the C code, they failed to provide a mechanism to suppress the warning dialog box for Windows (it can be done a function that uses with signals in linux though). Since this is a one-shot gig anyway and I don’t have the time to figure out the dependencies and recompile their code chain, I came up with something ghetto: automated mouse clicker.

It’s the kind of solution that is not too natural to come by for people with finer control over computers (aka, software engineers), but immediately obvious to middle-school level script kiddies.

I have to admit I almost lost the ‘street’ knack as it took me an hour digging through the documentation and code base to find a ‘proper’ way to do it before I even gave the ghetto patch a thought. That’s how seasoned engineers can get pwned by noobs who ‘don’t know a damn thing’ but ‘gets the job done’. Luckily, I remembered to switch hats early enough this time.

A ghetto trick or two can be used ONLY when we are really sure that it’s a one-time gig that won’t be reused. Any attempts to extend the one-time-wonder can only attribute to pain and misery for everybody, as a recurring theme in software and product development projects.

Sounds like a familiar situation at work? It’s always that one small thing your client asked you for. If you hack something up quick-‘n’-dirty and it worked, they are going to say, ‘by the way, one more one small thing…’. Lather, rinse, and repeat and soon you’re buried in brown, sticky foam.

This can be explained by the life lesson I learned in my first summer internship during high school: people in general don’t know what they really wanted and they don’t communicate well. Me included. The soft-skills coaching received at Stanford helped quite a bit, but I still consider myself ‘not there yet’.

Typically, your client is going to ask you for something specific (which is not what they really wanted because they haven’t figured it out yet) and keep revising and making sharp turns at your expense to make up for the ‘errors’ as in ‘trial-and-error’.

This is not a win-win scenario. It’s a tug of war between you and your client: you want your client to do their homework to figure out what they wanted and your client want to crap-shoot at your expense. It creates tension between you and your client. A work contract (or a specification agreed upon) might protect you from blame, but a client that doesn’t get what he/she wanted (regardless of who is at fault) is not going to be happy about your work.

One way out of it is to ask your client to start with a vague, underlying theme of what they are trying to accomplish. This way they won’t be overwhelmed by the pressure to get all the detailed specs right. If you have a long term relationship with the client, it pays to learn what are their general ‘interests’ are so you can piece the fragments together quicker. Gradually, you can ease them into thinking through their underlying goals aloud and you can take the opportunity to explore how you can help them accomplish it.

Guide them through their thought process, and maybe show a little prototype or design to help them visualize how they can accomplish their goals (through you). With the big picture in mind, you can make educated judgement, fill in details, and decide what intermediate/iterative steps are needed instead of letting the client unwittingly micromanage you based off his/her solution approach by saying ‘I need one small thing quick…’ one at a time. You are now in control over the project and in a very good position to help your client meet his/her true agenda.

It seemed like more upfront work to meet your client halfway and do part (or half) of their homework, but for anything other than a short hit-and-run, it’s less total work for you and a happier outcome for both. Using this approach, I was able to deliver a last minute change in ‘1 minute’ because the software architecture I designed was tailored towards the client’s underlying goal, so the feature he forgot to ask for was naturally built in and only requires one line of code to turn it on despite I hadn’t explicitly planned for it.

The bottom line is that humans are clueless (at various levels) and they want to further their interests (by doing something). If we take both parties’ interest into account and spot inefficiencies that we can correct, there’s at least an approach where everybody wins. Game-theoretic approach and market equilibrium is ‘optimal’ only when ‘technology’ is held unimproved and there is no on-going relationship between parties. Life doesn’t always have to be a war or struggle 🙂