The importance of a step back to find quick wins

Captain's log, stardate d576.y37/AB

MarsBased Development Management
Xavier Red贸
Founder & CTO
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 馃槂

Share this post

Related Articles

Not taking decisions is frustrating

Not taking decisions is frustrating

As much as you can read about business and about how to manage your own company, you will never be prepared to face this hard reality: slowly and gradually, decisions take more and more of your daily time and mental bandwidth.

Read full article
Remote is the new cloud

Remote is the new cloud

One of the good things the pandemic has brought us is the normalisation of remote work. In this blog post, I share my opinion of the new tsunami wave this will bring and its rippling effect that will have on society as a whole.

Read full article
Open door

Be more available to the rest of the team

At MarsBased, we like to review our workflows, tools and policies every now and then because what it used to be good for us, might not be the right fit now. For instance, last year, we changed our project management tool from JIRA to Linear.

Read full article