From a coder’s point of view there are a lot of things that lead to high quality code. The ability to stay calm and focussed helps make good decisions on the code. Then there are things like readability, maintainability, the presence of unit tests. As a programmer who does a lot of work with other people’s code, those are important to me. I’m currently working on a Moodle site and there are times when the 1000 line functions and nested statements favoured by the Moodle programmer in a big hurry make my heart sink. It’s like trying to read a book that has no chapters, endless sentences and a confused maze of circular footnotes.
But from a client’s point of view, these are invisible behind the scenes things. What they worry about are the finished product. They ask questions like: does it work? How long did it take?
I’ve worked with many clients, ranging from large digital agencies with multi-million pound clients to small businesses needing a few upgrades. Web sites are never finished, there’s always more work to be done. It’s an iterative process which is never finished, once you’ve finished something, it’s only a matter of time before it needs to be revisited and additional functionality written for it. I’ve found that in order to keep myself motivated and also to keep my clients focussed on keeping the site moving at a reasonable pace, I’ve needed to be very clear about outcomes.
When a client comes to me to ask for a bit of work, they often have a particular outcome at the back of their mind. Getting them to communicate that to me is often about asking the right questions. The questions I want answered are:
What is a good outcome for this bit of work, what will get this work signed off? It seems obvious to the client what the answer to this is but I find that this is an area where differences in expectations can generate difficulties later on. I had a client 6 years ago who wanted a beta release of his site. Generally, in software development, that means getting a site working in a basic way and then ironing out the bugs in a later phase. What he meant by beta was a final polished, pixel-perfect, bug-free version of the site. Not checking my assumption cost me a lot of extra hours working on the finished product.
When does it need to be finished by? There’s often a lot of haggling around this one because software development and time estimates can be a cause of a lot of stress for both client and developer. I was asked to refactor a site with 300,000 users about 4 years ago and when I took a look at the code, it was fairly obvious that there were considerable time pressures on the original build. There were lots of copy and paste bits of code and lots of signs of short cuts. The bitter (and somewhat unprofessional) comments in the code were also a bit of a giveaway.
Time is something that most of us have a bit of a fraught relationship with anyway and adding in delivering code can it can be worse. After a lot of experience, I have a more intuitive feel for time on delivering code. Sometimes, there’s something that doesn’t feel quite right about the timeline, and then it’s a case of going back and checking.
Just clearing up the assumptions that everyone has is a good thing. It can seem that I’m asking obvious, even silly questions. Yet it is worth it to get a clear idea of what is needed and the processes that need to be in place to make the work happen.