The Customer Service of Web Development

We devs sure love to start from scratch. Each time a long time has passed since a site was last rewritten we suggest a new rewrite, because who wants to deal with the old tech that nobody wants anymore.

A new site emerges and it does 25% of the things better than the old site, 25% just as well, 25% worse, and breaks the remaining 25%.

In my opinion this is pretty bad service. It is understandable though: starting a new site lets devs get into all the new cool stuff out there and learn them. It gives experience on building a thing from nothing.

The other side of the coin is that by working this way we are really giving bad service to everyone else. We waste time and money rewriting something that has already been implemented. We waste site users time as well: broken bookmarks, broken links from other websites and social media, the need to learn a new UI, the time wasted complaining about the change as some of the old (good) features didn't get to the new site...

This craft is not only about doing things. We are also the invisible customer service people. The decisions we make have impact to thousands of lifes. When we choose to replace old with entirely new we are being disrespectful to those that made the existing site by abandoning it. We also often choose to ignore users. Even when listening to user feedback we interpret it the way we want and make it fit with what we have planned instead of looking it from the viewpoint of what exists and how to make that better.

These are the reasons why so many full site rewrites are bad. People do adjust of course and maybe eventually accept the new one. But does it really have to be this way?

How to fix this

You have to start by having respect. You have to give value to what there is instead of looking at all the things that are not the way you would like them to be. You have to be willing to give your time and effort to understand the existing. You can keep the old codebase and gradually modernize and improve things as you go. You can even put entirely new stuff that runs on new tech by replacing just parts of a site.

It may take some work to adjust the old code to work with this approach, but instead of throwing a massive change and overhaul to your users you let them take changes in gradually.

You can also start an entirely new codebase, but build it as compatible with the old as possible. Keep the urls. If you must change them, provide a redirect as close to matching content as possible. If stuff must go provide a 410 with possible helpful content and links instead of a 404. Make the design reflect the old one as much as possible, make minimum changes to take in the required new ideas. You can always change more later.

Being of service

You won't be getting a lot of direct feedback for being a good guy in this "customer service" mindset. Most often you just have to rely on the fact that by doing the right things, caring, and putting in as much effort as you can to thinking about what you are really doing, you are making the world a better place.

When you have this attitude you will do things differently and people you work with may notice this. They will see that the code you provide is robust. They may see that the UI you build just works well. They may also occasionally go "I'd have never thought about that!".

You might also start to think about the amount of code you push to users. That too much code is harmful, and that maybe there are ways to provide more with less. Instead of throwing in more libraries each time you have a problem maybe it is worthwhile to do it yourself. The result won't do all the fancy stuff, but it most likely will have far less code and do just the minimum. And often that is enough and perfectly fine.

And maybe just sometimes some people like what you've done when they have just encountered a horrible experience somewhere else and end up to a site you have been carefully working with. It just works nicely with anything the user throws at it. They have a pleasant experience and come back again.

With this text I admit that I'm a craftsman sort of guy. I know the little things and details that are needed to build stuff that fits the need. I know how to adjust to the unknown. I also know something about the bigger picture. The way I think does not work with all teams and the way I prefer to code and do custom solutions is not favored in some projects.

There is one line I've heard: "This codebase is too big for that kind of attitude. We need everyone to follow these same patterns and coding styles. We have to make great developer experience so everyone can contribute."

Then break the codebase into smaller projects and create smaller teams. You can always do that. Everyone gets their own project and get to have more influence on how things should be. These things are the stuff that makes devs happy.

But now I think I have been going on for long enough. Hopefully this brought some value to you despite being yet another text that I only worked on for a relatively short period of time right before it is time to go to sleep :)