The importance of a step back to find quick wins

This week, I want to highlight the importance of taking a step back to analyse the applications we develop for our clients.

Being a consultancy means that all of our projects are for third parties (clients) who hire us for our expertise in Ruby on Rails or because they need more manpower and thus need extra people to increase their development pace.

Our clients always tend to prioritise new features. They feel that advancing equals building new features, but we need to advise them to take other factors into consideration.

Building new features at the expense of code quality, for instance, is the exact opposite of what books like Rework describe as the best path to progress as a product. Rework, like many others, advocate for a slower pace in developing new features or, as David Heinemeier Hansson put it:

You're better off with a kick-ass half than a half-assed whole.

Not only code quality, but there are other factors to be taken into consideration, like coherence across the product, test coverage and developer burnout, just to name a few.

I'm convinced that we won't be able to convince our clients to behave as we would love to but at least we need to try to make them understand the implications of not investing enough to fix or prevent the issues described above.

A couple of examples from the past weeks:

Allocate time for quick wins

I received some emails from NewRelic that one of our clients' servers were having memory problems three times a day. After analysing the whole thing with the lead developer in the project, Oriol, we found that the servers were consuming more memory than the max allowed memory we had configured. We decided to invest some of our time to optimise the configuration to eliminate these issues. So far, so good.

However, within these ten minutes of analysis we also found a request that was performing poorly because the database missed an index. After identifying the problem, the solution took five minutes to implement.

For some users, it meant reducing some requests between four and five seconds.

That's what I call an instant win.

For this other client, we have Airbrake running on our servers. Airbrake is a great tool to log application errors and exceptions, but in big projects, with known bugs, it can generate a lot of noise.

The other day, we decided to review the list carefully and we found 2 bugs affecting hundreds of users (nothing critical, but worth looking into) that were easy to resolve. Solving them was also an instant win which made a massive difference.

Review past structural decisions

For this other client, We are working with five applications deployed on different servers. All of them are pretty similar (the difference resides in the content, for the most part) and they were deployed from different branches (app/platform1, app/platform2, etc)

The problem here was that every time we made a change to one of the applications, we needed to replicate it to the other ones. Merge conflicts were huge and time-consuming.

Juan Artero, our main developer in this project, saw that this was very painful and after analysing different solutions he designed a system with a single codebase to serve all the different applications needs. I was not convinced at all at first, but after seeing it in action I have to admit that the time invested was worth it, and now he's investing less time in fixing merge conflicts and more in developing to meet the client needs.

---

What's the moral here? We wouldn't have found these clogs in the machine if we had been entirely focused on delivering new features at the expense of performance or the long-term maintainability of the projects.

I know it's difficult to stop delivering features to our clients and take some minutes to analyse how our applications are behaving in production. However, we can't forget to do this from time to time because sometimes there are instant wins which will create a huge impact to the end users - and therefore our clients - waiting to be discovered 😃