Repost: Why the client hates your software

Here is a repost from my old blog, which is now lost. Posted in 2003

———————————————–

It’s been over two years now since I have sworn off being a web developer and software hocker. I didn’t do this because I had to, I did it because it became clear to me that I could no longer do work that I wasn’t passionate about. I applied this thought to every space in my life that made sense. I made family a passion, I was passionate about the girl I love, our cat, my belief in god, I had passion as my driver. I am still learning about this, and I believe I always will be.

In this change, I came to hate the essence of the software I had been producing, even when I was making a lot of money doing it. I saw this because there were two parts to what I was doing. I was building tools that had FIV (the virus which causes featureitis) and the other half of my time was spent fixing the screw-ups of other vendors (this is where I got to see how much the client suffers).

At this time, I began to become fascinated by community building – I fell in love with the idea that people could connect with each-other, online, on a meaningfull level. I saw that we weren’t stuck in the old software world forever, we could make software that meant something to the people who used it. I got to do some cool work on internal communities with some big organizations, but I saw that I couldn’t make much of a business of it at the time, the dot-com boom was still rolling along, albeit on it’s last legs.

It was then that I noticed on key fact: The client hates the software – and he may start to hate you.
Software, web apps, utilities, databases, they all cause headaches. I wish I could bet on this at the casino, because there is almost no argument here. So little software is actually well made that organizations have been forced to funnel money into IT and the only cost-effective training is teaching the employee how to run damage control when needed. This is true for all software, open-source included.

It is still true however, that: If you don’t know a thing about the software, you’re going to look like an idiot.
If you are building a business on this software, it doesn’t matter who you are, you have to understand the software. Even considering the last point in this post (coming up), the tool does matter enough that it can break your relationship with the client.

There is a different way: Be passionate about your build, and connect that to the client.
The fact is, most developers are incredibly passionate about what they are building. The software that a programmer develops is most likely a major source of pride in his/her life. It is somewhere between the coders, the sale department, the management, and the client that the love gets lost. The connection between the programmer and the client needs to be made again – let them smile at each-other, and let your developer tell the client a few secrets here or there, or fill a feature request in record time, just for them. This is the only way you can foster a real long-term integrity. The easiest way to start is to have your developers blog on their own section of your company site.

No matter how good you think you are: Your software doesn’t matter
In the end, what matters most is how well your client can actually use the software. There is no other result (including your bottom line) that will sustain you over the long term. By being in the trenches with them and pushing the adoption curve, you will get impromptu phone calls from your client in a few months, just to tell you how well everything has been working, and just to say thanks.