Is Your Client Your Ally?

One of my first projects as a young developer, who was taking his first steps into software development, was a RUP / CMM / Waterfall text-book example of how successful projects should be run using Big Design Up-front Methodologies. It completed on time, it was on budget and it was transitioned successfully.

We had every single scenario and flow of the system documented. Every single change that was not elaborated resulted in a change request for which the client either ended up paying us more money or giving up the idea of wanting the change.

If you were to consider it a war, we won.

This so-called-success was one the biggest failures in my life as a software developer. A failure that turned me into a Shameless Developer and taught me things I would never have learnt otherwise. Later on I was also called in to support the crap the entire team (me included) had written and the same project also ended up teaching me how to refactor code ruthlessly.

Folks who worked with me in the project wondered why I considered the project a pathetic failure when it was transitioned with a successful UAT and we had a grand lunch to celebrate the project success. Here’s why:

Any of these sound familiar?

During the time we worked on this project, dialogues like these were a part of our daily lives. I heard these from team members more than once every day. It was a war and we were in it to win it.

Occasionally we would also hear whispers from the client which went somewhat on the lines of – “Umm… I’m not sure if this feature adds a lot of value” or “I wonder if we can…” – but who cared? We were building as per the approved specification.

We had spent a few odd months writing use-cases, test-cases, module specifications, low level system specifications, system requirement document, functional specifications, technical specifications and tons of other documents a lethal combination of RUP and CMM would require you to write and now we were there to ensure that they either stick to those documents or pay the price if they bothered us with changes while we were busy developing.

We had been constantly firing “them” with pages and pages of these documents, constantly reminding them that we were very organized team of guys who worked according to a systematic process. Anyone watching us, would have guessed that we were building a plan for a bridge, a building or a rocket when all we were building was a shitty piece of software that would hardly ever get used by anyone.

After sleep-less nights, meetings and brute force programming using incompetent mediocre developers, we, the team, delivered the project. The delivery and the UAT was the final blow and we got it over with before the client could even realize what the hell happened.

Things like usability, user experience and the like were never documented. So when they would come up asking us to reduce the number of clicks, we showed them a functional specification document, told them it was a change request and asked for more money.

More often than not they chickened out, which was good because we could comfortably meet the time-line. If they paid more money and wanted the change-request done, we would ask for more time and that would still allow us to comfortably meet new dead-lines.

After a few months of rigorous fighting, the project was on time and successful.

The client was defeated.

And that, by the way, is precisely why I consider the project a pathetic failure.

When I completed that project, the feeling of being a part of a team that had failed at achieving their fundamental undocumented-goal of building a system which is usable, wasn't particularly amusing. The fact that no-one in the team had even realized how badly they had failed, made things even worse. I went ahead and made a commitment to myself that I was going to get better at building good software and providing true value to my clients project after project.

When I made the commitment to myself, I thought that this is the lesson every programmer out there, who has been in the business of building software for more than a few kilo-seconds, must have learnt this same lesson the hard way. After all they don’t seem to teach these things in programming schools.

Years later today, I've lost touch with everyone from that project team but even today, all over the world, I see countless developers with years of work experience behind them, fighting their wars against their clients and winning every single one of them, one after another. With one war over they move to another and then another. Defeating client after client, not caring or giving a dam about developing deeper roots or getting better at what they do or even attaining enough skills to be able to provide true value to their clients.

Take a trip some of the larger software consultancy body shops in India and look around. You’ll be able find complete battalions of guys who specialize in RUP / CMM / Waterfall documentation which can even confuse veteran developers leave aside unsuspecting clients.  Walk down the corridors of these shops and you'll see developers talking about - SRS, FTC, UTC, CRQ  and countless other abbreviated document names, but you'll hardly hear them having white board discussions on how the code or design can be improved.

Everything, ranging from the abbreviated document names, long winded processes, bulky documentation which has no respect for DRY, code and design done with contempt for KISS and Orthogonality, is focused towards one goal – defeating the client in a war.

A huge number of these guys have been trained into believing that Big Design Up-Front is the only way to build software and that if a company isn’t doing RUP or CMM, it probably doesn’t know how to build software and if a team does not cross the size of twenty people they are not really building a good software. Every once in a while I will interact with folks from these body-shops - folks with a mind-set who believe that If a guy talks about backlogs, daily scrums and weekly iterations through sprints and particularly getting the client involved in active feedback, he probably is an alien who is contaminated with the Agile virus.

No wonder more than seventy percent of the software that is built, fails. No wonder software professionals are the most hated group of professionals in the world after lawyers. :)

Almost instantly after my first so-called successful project, I turned into a thick-skinned developer who fails early and fails often and started working for organizations / clients / managers who, till date, thankfully, have allowed me to fail early. Failing early in projects all these years has allowed me to be a part of projects which both the client and I can consider – successful.

Every single project that I’ve worked on since then, has been a war against time, a war against badly written code, a war against huge complexities and a war against so many other things, but thankfully, not a war against the client. I sure do hope things continue that way for me, project after project.

This is not about how you build software or your development process. After all, we all build shitty software. This is about "working with your clients" and providing them value for money. If you want to come remotely close to winning the battle of building decently acceptable software, you may want to start by having the client on your side.

The next time you write a thirty page functional specification for the login screen, followed by a twenty page login test case and send it to the client asking them to review it in a couple of day, ask yourself if you’re really helping them. Would they rather by happy seeing wire-frames followed by a quick five minute recorded screen capture video where you run them through mockups and re-iterated their requirements? Can you spice up your functional specifications and tempt your clients into reading them? Maybe they appreciate slightly  better ways of capturing functional specifications - How about trying to convert you functional specifications to a wiki?  

The next time the client tells you they can’t send you the steps to reproduce that bug, maybe you might want to do a code review on that module and check out if there’s an erratic bug hiding somewhere.

The next time all your test-case documents come back executed successfully from the Quality Assurance but the client is still not happy, maybe you might want to increase the code coverage your QA teams are testing. You may even want to consider writing a few Unit Tests to test your code and growing the number of tests over time to increase coverage.

The next time the client asks for a tiny business logic change and you find yourself complaining that they should have said that before - maybe you could have done a better job at making it configurable rather than leaving it hard coded in there. Maybe you never cared about Orthogonality.

Ask yourself - Are you sending out builds frequently? Can your client run your builds? Are you seeking constant feedback? Are you iterating fast enough?  

Rather than spending hours in building support for law-suite in our processes and documentation we as developers would be much more loved and respected by our clients if we spent this same time building good software and making life simpler and better for them. Confusing the client with documents is easy. Simplifying their life and building software that adds genuine value is hard.  

In the war of building good software, you have enough to fight against. Don’t rage a war against your clients. Make them your allies.