Quick and dirty fixes

Speed is often a defining factor when it comes to making products available online. But if we aren't careful, it can sometimes cloud our ability to evaluate situations. We can hear other people telling us how they applied quick fixes in their work, but we must question whether this approach would be suitable in our context too.

Being fast doesn't make us right; it's often the opposite. We can do fast errors that cost us even more time to fix. Debugging is where we spend most of our time. But the result of these fixes must be conscious and not random. Otherwise we risk affecting negatively the architecture of our product.

It's unfortunate that making quick and dirty fixes often involves building "on top of the top". We can see websites that include hundreds of libraries, simply because it's convenient and rewarding to see everything working. We even try to "fix" one library with another, which makes chaos the norm. But it's not our ability to compose these libraries that makes our work good. It's the stability of the solution, which excludes the idea of building a giant house of cards. We don't want things to start falling apart by the slightest wind.

We should ask ourselves to what extent the libraries we see and use were a result of quick and dirty fixes and whether their application will further increase this tendency. By choosing a library to build on, we agree with its philosophy and the way it will shape our product.

Quick fixes can be counterintuitive, so they may require additional explanation for other people. Comments can help, but linking to the original approach and the person who invented it ensures that we give credit even when working fast. If a quick fix serves our own convenience now, but has to be decoded by many other people later, it will be costly.

Working this way gives a bad example, because the next time a fix is required, it will need to be faster for practical significance. Moreover, people who work on it will be measured on speed and not accuracy, which is bad.

Very often quick fixes target not the real problems, but their side effects. To be aware whether we are fixing the right thing, we need time to find the root cause of the problem.

Instead of making things quick and dirty, we should try to create simple products of extreme value with the least amount of components. This is hard to do and requires no less knowledge than the ability to include libraries.

Quick and dirty fixes can be motivating, but we must be aware that nothing changes radically in a moment. Even if we think so, this is a result of the state of heightened emotion we are in. A fix that is working today might not be working tomorrow.

If we claim on words that our product will work flawlessly, but then prove with our behavior that we do things the quick and dirty way, we have an integrity problem.

Quick leads to dirty, which makes for low-quality products. We throw them away, because they aren't immediately useful or in any way beautiful.

When we work on a small product, quick and dirty might seem to make sense until we realize that everything that we do and put out there is judged by the same criteria. With quick fixes we undermine our future, so we need to be more thoughtful about them. Having constant quality of work is a sign of professionalism.

Not everyone who writes code is a programmer. Programmers have many users, who call themselves programmers, but are unable to create a product of higher complexity with unique place on the market. These users often fall for the quick and dirty way of doing things out of feeling helpless. If we are aware of the feeling, we can also suppress it.

When everyone else works this way, we need not follow. This shows the extent to which we are ready to learn from each other, even when the practices might not be good for anyone. Exclamation mark.

We need to explain to clients that quick and dirty isn't how we work and that it will be better for them to seek another service provider if they expect that from us. The work has to be liked equally well by both parties and if the designer won't be mentally satisfied with the result, it may be time to work on a better project with another client.

Quick and dirty doesn't work from a business perspective, because it risks the trust between us and our customers. The level of trust we want must be reflected in our approach towards the work.

Should we leave the company where we practiced quick and dirty, others will have a problem to continue where we left, especially if their style of work is different. Our former haste could then become a potential bottleneck. We need to always ask ourselves how sustainable is what we do, especially in the long term. Our work must be done in a way that whoever comes next will be capable of doing it.

By doing things quick and dirty, our freedom of thought gets in danger, which makes it easier to be replaced by a robot one day. Then we better be quicker.

Best products are slow and clean, so we need to appreciate more what makes them good enough to be bought.