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 and dirty is the result of the high efficiency we seek at any price. Once we start to work this way, there's no way back. We might even get hired because of doing it, but this doesn't make us necessarily better. It's only that clients want us to behave this way. We don't want to be known for fixing small things quick and dirty, but for creating whole solutions.

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.

Not everything can be considered initially with our product. A fix later implies that something with it was already wrong, but this isn't always the case. We shouldn't allow functional bugs to become conceptual problems. By applying quick fixes to functionality, we adversely impact not only the product, but also the concept quality. Every subsequent patch for Windows increases the need to replace the whole OS. Quick and dirty shortens the lifespan of our products and increases the likelihood that further maintenance will be needed. Google tries to create products that are maintenance-free.

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.

Working is an act of love. If we treated our product as we liked to be treated by the people who bought it, we wouldn't even think of doing things in this way. We don't need a half-baked solution, because the client will taste 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.