When there’s no one paying, everyone pays.

One of the argument I’ve heard the most is “Yeah, it’s nice to have, but no client is going to pay for this”. That reasoning seems to be right on spot, not every clients are going to appreciate everything you did for them.

In software development, there are things that the client will get directly from us, and something else that is not direct benefits for them. The client would not see any benefit from that latter, so do some of the developers and some of the management. They all care about deliverable. Things that does not ship means nothing to them.

But, is that really the case ?

Let says, I have a product, written in-house, accompanied with a pocketbook size of build instruction. It takes the developer busy for at least 3 hours to setup. Imagine you have a team of 20 developers who have to do their own build. That’s already 3×20 = 60 hours of the waste of time. And I’m not saying that everyone will do their build only once for their lifetime :).

Oh, did I mention … “at least”?

And who is paying for that 60 hours? The client, of course. However, it will quickly returns back to the company. Having the developer spending time on the build means they take more time to response to the change, or may be the production issues. Slower to response means less client satisfaction, that leads to clients leaving. That’s the last thing you’d hoped for.

Also the developer would not happy about this. In worst case, they will leave the company. For milder cases, they are going to cheat. Personally I think most people like challenges, but don’t like difficulties. They will cheat, for sure.

In my example, I found that many people keep using the same build for many work item and for many years. Using the same builds on a items that based on the same product version is OK, of course. However using it all the time is considered a very bad practice, as software evolves as time goes by. I have seen a guy who use the 3 years-old code to work on a very recent item. How can we know that that code will have the same behavior as the most recent one ?

One more epic example, some people I know refused to work for that product at all. They said it’s to difficult for them. I’m not blaming them, though, it’s indeed very difficult. Some of us just happens to have more endurance. Well anyway, that results in resource starvation. The backlog list will get longer and longer as day goes by. Will the client happy about that ?

Ideally, all code base should takes one step to build. That’s the suggestion made by many gurus, and I heartfully believe in it. I mean, things that can be automated, should be automated.

Anyway all the change we do is to make sure to serve the client the best service, in timely manner, to win the client satisfactory. Some changes are directly beneficial to the client, and it’d be acceptable for them to pay. Some are not, and for that it’s up to company to consider investing in. At the end of the day it will save more than we’d spend.

I’m not going to say that every changes will be beneficial, or even worth the investment. However I believe that any idea, any suggested improvement should be reviewed and considered. There are too many good idea discarded just by the word “no one is going to pay for it”.