“Quick and Dirty” is not quick
In an industry that is focused on “time to market” and “gathering data points” it is crucial to be able to have a working solution FAST. This is apparent in the fact that most teams I know have some sort of agile process going on and usually start projects with an MVP solution.
When considering a fast solution, many will use the term “Quick and Dirty” to describe the suggested approach. As you probably know, “Quick and Dirty” means that we will make a sloppy solution fast, just to make sure we deliver on time and don’t mind the quality as we will for sure of time to fix it later.
There is a common saying in Hebrew that goes “if it is temporary, it is actually permanent” and if you have any experience in software you know this statement to be true. Our “Tech-debt” backlog is overflowing with refactoring tasks of “dirtiness” left behind after “quickness”, and we never get to it because we have other “quick” solutions to work on.
Why is it so bad, you might ask? We did get the job done quickly, didn’t we?
Well, for the short term you did. Not for the long term. Messy code costs in reading time, debug time, defect handling time, refactoring time (when we need to make unplanned changes) and the list goes on.
If we look at team velocity over time (and we should) “Quick and Dirty” is in fact not “Quick”, it is just “Dirty”.
What then should we do if we need to deliver fast?
We need to deliver less. Or as my favorite uncle recently twitted:
If we don’t want to compromise the quality of our solution and the deadline and workforce is fixed, the only parameter we can play with our the requirements (this is a derivative of the iron triangle principle of project management). This can be achieved in a few different ways:
Challenge the requirements
Is everything really needed? Are they all requirements needed now? Can’t we achieve what we need without adding new code?
Ask these type of questions, and you might be surprised of the response. Don’t accept an answer like “everything is urgent” because by definition if everything is urgent it also means nothing is urgent (think about it).
Validate the requirements
Don’t rush to the finish line only to discover what you delivered was not actually what was needed. Before you start, make sure you know what you need to deliver, and you have how to measure the success. One great way to achieve this validation is to use BDD (start with high-level, business-oriented tests) but a meeting with the product owner to make sure you are aligned can also do wonders
Design a dimple solution (KISS)
Do we really need to build a new front end framework just to render a table with a few drop-downs?
Try and spend time on separating your concerns correctly, and then build the minimum you need in each area. This way you save time by focusing only on what is important while allowing future changes (that will undoubtedly come) to be done with ease. When considering an architectural or operational decision, ask yourself if this is a decision you can postpone to later. A good example might be starting with a small project that is well separated to different modules, so we can deploy it as multiple microservices in the future.
Plan for success
Before you start implementation, make sure you have a mechanism in place to make sure you know you delivered the right thing. In simple cases, this can be a successful test suite (manual or automated) and in more complex ones this can be some sort of goal we need to track based on metrics or log analysis. If we did the previous steps, and is part of our routine, this should be an easy task, especially when done upfront and not after the fact.
Have a standard process
I like this quote attributed to US Navy SEALs:
— “slow is smooth and smooth is fast”.
Continue writing tests, adding log prints, doing code reviews and any other mechanism you have to maintain quality even for urgent projects. Rushing to the finish line and spending the same amount of time writing code on figuring out why it doesn’t work is counterproductive.
Conclusion
Quick and dirty slows the team down over time, and in many cases is not even quick in the short term.
For the reasons I mentioned above, I suggest starting an urgent project like any other. Challenge the requirements, make sure you understand them, design a simple solution that answers them (and can scale when they change), and make sure you know how to measure the success of your deliverable.
Adding dirtiness to your project is a slippery slope. The more you do it, the harder it will be to fix later.
