Dealing with a client that is resistant to change

head-in-the-sand

Recently, I met up with a client that I’ve been doing some side work for to go over my proposal for a rewrite of one of their applications. The existing application was written very quickly with very little effort put into quality, testability or maintainability. It was initially intended to be used internally but has since been sold to a client. He wants me to upgrade it so that it can be sold to other clients and they can make sure that it doesn’t fall flat on it face when it takes on a load that it was never code to handle. In many ways, this is a very typical scenario.

My approach was to spec out the application as if I was writing it from scratch. I considered the existing implementation an artifact that expresses some of the business requirements for the version 2 application. I tried not to let it guide my design in any other way. In the end, I came up with a plan to implement the application using some industry best practices for testing, maintainability, code quality, continuous integration, deployment and support. I knew my proposal was going to cause some waves because this client is used to writing applications in a very “cowboy coder” kind of way….just get it done quickly and as easily as possible. Let’s just say I was not disappointed.

My client had a lot to say about my proposal so we spent about an hour going over it. Some of his concerns, question and comments were very interesting to me. I realized that I’ve been in this situation a number of times and I’ve had to answer very similar questions. I figured I would capture some of the highlights of my conversation here for your enjoyment.

I’ve been coding since I was 7! I’m comfortable with the way I code and don’t really see why I need to change.

changeFirst of all, who codes when they are 7?!!! Not me, that’s for sure! I was too busy watching cartoons and coloring. I think he was just exaggerating for effect. In any case, let’s look past that and focus on the “I’m comfortable with the way I code and don’t really see why I need to change” part. This can be a very difficult statement to respond to…especially when you don’t think that the person is very good developer. You want to make your point, but you don’t want to insult the guy in the process. In my experience, these statements usually come from someone who hasn’t had a lot of exposure to different ways of developing software. Either they’ve spent a lot of time at the same company or a they’ve worked for several companies that do things in a very similar way. The end result is a developer that is stuck in his/her ways and can’t see, or is unwilling to accept, the benefits of doing it any other way.

This is why I like to point out that I have worked for a lot of different companies, in a lot of different industries in my career. I’ve been exposed to many different software development processes and a plethora of tools and technologies as well. I’ve done some really amazing things but I’ve also had my share of failures. It is the aggregate of all of these experiences that has shaped my approach to building software. So, maybe you are comfortable with the way you’ve always developed software but what I’m suggesting is that there are other ways to do this that can improve the software development process, the quality of the product you put out and the maintainability and supportability of that product as well. Yes, there is a slight learning curve, but once you turn the corner, there is a considerable upside to using these new tools, technologies and processes.

This is overkill. I just want a simple application.

I understand why this client would think that a more sophisticate architecture is overkill for such a small application. In his mind, it doesn’t do very much and there is no reason to do most of the things that I’ve suggested. I agree that it could very easily be written without all of the advances techniques and tooling that I’ve included in my design. In fact, it has already been written that way. The reason I was brought in for this project was because, as it is currently implemented, it will not support the type of load and scale that is anticipated. My job is to make sure that, if you start onboarding more customers, the application won’t fall flat on its face under the new load.

You should also consider this an opportunity to introduce these advanced architectural patterns, tools and techniques to your development team in a way that doesn’t interfere with their velocity or extend the timeline of the project. This is a completely separate application that I can work on without impacting other developers. Furthermore, I have a lot of experience building applications using all of the tools, techniques and process that I’ve included in my design. My velocity will be considerably better than a developer that is just leaning about these and trying to figure out how to implement them. I can very quickly develop this application and then do a presentation to the rest of the team where I go over the key aspects of the design. I can show the other developers all of new tools and process that I’ve implemented and go over the benefits and drawbacks of using them. Not only will they be introduced to some advanced tools, but they will also have a reference implementation where they can see them in action and how they work together.

I don’t like using tools written by other people because I feel that, by doing so, I can only be as good as they are. If I write my own tools, I am free to innovate and be as good as I can be.

I’m all for innovation, but you should focus on innovating on the things that are particular to your business and not on problems that have already been solved. Instead of spending time and money building your own logging library, for example, you could be spending it on innovating in the business critical areas of your application. Focus your efforts on the parts of the application that deal with your business domain and leverage existing solutions for other outlying systems that support it.

Furthermore, we should stop thinking that we can always do things better than the other guy…we’re really not that good! There are a lot of extremely intelligent people out, there that are much better than you and I, that have spent a lot of time developing, testing and maintaining these tools. We can reap their benefits without taking on all of the cost, effort and risk related to building them ourselves. And even if we did build our own versions, odds are they wouldn’t be as good as theirs! Some of these tools have been out for decades and have been maintained by dozens, if not hundreds, of really intelligent developers that are passionate about that problem or technology.

Nuget is a Virus! I don’t like using it.

I have to admit, this really threw me for a loop at first. I thought about it for a few seconds, as he elaborated, and I think I understood what he was trying to say. He thinks that Nuget can be a way for bad, untested software to make its way into your application. The ease with which we can pull large amounts of code into a solution scares him. I can see how this can be a concern but we are not talking about using packages that were developed by Joe Blow developer. We are talking about NUnit, StructureMap, Log4Net, RhinoMocks and other similar tools. These are software packages that were written by reputable developers and/or companies and have been used in the industry for years if not decades. They have proven to be reliable, stable and robust solutions.

When it comes to other packages, you have to be a lot more thorough with your evaluation of the library before you decide to import it into your solution. Don’t just install any old Nuget package because it claims to solve the problem that you are looking to solve. Do some research, see who else is using it or even write a sample application where you can test it out and see how it performs before you add it to your application.

In the end, I was able to convince this client that it was worth implementing the design that I had proposed. Although I don’t think he is completely onboard with everything that I said, I do think I made a lot of progress in changing his mind about the value of using proven tools, technologies and process to build robust applications that are easier to develop, test and support. Now, it is up to me to execute on that promise. I know that if I deliver a product that lives up to all of the hype, it will go a long way towards making him accept this new way of building software.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.