Emergency Driven Development
If you work in software development or IT you might have encountered a long list of acronyms, in fact there is an acronym for everything!
Just to mention a few we have CI-CD (which is not a rock band), OOP, SOLID for design principles, SMART for criteria to guide in the setting of objectives, and counting.
When comes to software development process, the DD (Driven Development) in the acronym, there are different approaches, that usually are best practices. Maybe the most trending nowadays is the Test Driven Development (TDD), where tests are written for every requirement and code is tested against it.
Acceptance test–driven development (ATDD) focuses more on the user and tester experience, and software is tested against acceptance tests, instead of unit testing.
While Behavior-Driven Development (BDD), which combines the former two, includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation.
Or another approach is to write documentation first, Documentation-Driven Development (DDD), so that every feature of the application is well documented.
Most of just discussed are best practices, but the world out there is hard and difficult, and many times is easy to fall in worst practices and bad habits.
For example you can have Asshole-Driven Development (ADD) or Cover Your Ass Engineering (CYAE), the latter being very common in consulting (more here).
EDD
Today I want to define a new acronym: Emergency Driven Development or EDD.
EDD is when you usually postpone something that has to be done until an emergency comes up, related to that piece of work, and you are forced to do it without any planning and quick. The task can be a refactoring, a missing feature or a bug which is left there and you will deal with it in the future.
When it happens that you face an emergency, which most of the time happens in production (obviously!) and with the most important customer (obviously!), you don’t have enough time, at that point, to do things right, but you (or your boss?) start screaming around the office for a quick (and dirty) fix because there is no time (remember: emergency): so no technical discussion about the solution, no whiteboard drawings, no thinking at all: just go and patch it the quickest way possible.
When the emergency is handled you probably know within yourself that you should have a deeper look at the issue and fix it once and for all, now that the emergency is gone. But, because you work using an EDD approach, you will postpone once again until the next emergency and the (vicious) circle is closed.
Can we fix it? And how?
But what brings to all of this? Here some reasons:
- lack in planning and roadmap, you start losing control on when do things and what to do
- the team is understaffed, so you actually have no time to work on some stuff
- but the main reason usually is due to people managing the project without enough awareness of what needs to be done and that are not able to give enough value to the important stuff (e.g.: doesn’t understand the importance and the consequences of technical debt)
Fix it is not easy as it involves a huge shift in the company culture. But in any case you can mitigate it trying to build a more robust roadmap (or even build a roadmap if you haven’t one at all).
Obviously try not to wait until the emergency arrives. Ok, I realize sometimes you need to wait for other reasons, but still you’re already losing the battle.
This brings us to priority: start improving how you prioritize your work, if you feel that an emergency could show up for a particular task don’t wait long to do it.
At the end: be honest, to yourself, to your team, to your company and make the best to avoid what can be avoided. In time.
