One of the things I hate about software development #1 — The word ASAP
Welcome to my new series of things I hate in software development.
ASAP — As Soon As Possible
A conversation happening right now on the planet:
Random stakeholder: “I need feature X.”
Naive dev: “When do you need it?”
Random stakeholder: “ASAP.”
Naive dev: “But what about Y, Z?”
Random stakeholder: “I don’t care; just make it happen.”
Raise your hand if it happened to you ✋.
How likely is it that the developer will implement this feature with an incredible level of care and quality?
Simple, it won’t.
The reasons I hate it
ASAP is lazy
The person asking you this didn’t bother to provide an actual schedule.
What kind of scale is it? A day, a week, a month?
Did they agree with other stakeholders? Are they fighting to get attention from the software team, and asking urgent tasks is their move to do so?
“ASAP” might be the joker card not to do any of those.
ASAP is bad
“as possible” translate to “what is the quickest hack you can do to have this feature online now”.
It is a total disregard to the quality of the feature, the general codebase, or even the value the functionality would provide.
ASAP is stressful
Ok, you need to do this thing NOW.
Hmm, but what about the others things you were doing? Should you finish these first? Weren’t they important tasks too?
What if doing this ASAP task would derail other plans?
Can you do more harm than good?
You have a lot of questions and decisions to make, which can add stress.
ASAP is wasting time
Now you need to ask around if this “ASAP” task is urgent. If it is, then you need to shuffle the current backlog to make it fit. What if there are contradictory priorities? Then you might need to escalate this to someone who can decide for the team.
Do you know what you didn’t do when you are thinking about those? Some focused work.
When is ASAP “ok.”
If a fire appears. For example, your software has monumental bugs; no login, payments are failing, etc.
You do have to look into the matter immediately.
You were most likely already doing that.
Telling you so might be a waste of time and annoy you on top of that.
Another case will be if you have an unexpected opportunity.
Let’s say you are developing a mobile app, and Apple wants to display your app in their Apple store. They need a customized version of your app by the end of the week.
Those two scenarios are the ONLY ones where it would be ok.
But there are also better alternatives than using “ASAP”.
Less haste, more speed
It is tempting to succumb to the dark side, to want to help, and jump straight to fix this urgent issue.
But remember that whatever mess you will create would be your responsibility.
It is not ok to compress the deadline by:
- reducing the quality of your work or the codebase
- not creating automatic tests
- skipping manual testing
- working overtime
The only way to do something faster is to reduce the size.
The smaller, the quicker.
If you can’t agree with the stakeholders on removing a part of the feature, then put back your headset, go back to your initial work. You can wait for an actual request that exceeds four letters.
Final words
I often had to go against my own will to implement those urgent tasks.
What I rarely saw is the benefits of stretching myself to do so.
I prefer to now answer “ASAP” by “ASAD”, As Soon As it is Done.
My definition of done.
What done means here:
- value is known and measurable
- the task is well-groomed
- my implementation follows the best practices (tests, clarity, readability, etc.)
- developers review my code
- to ensure no miscommunication happens, I demo the feature
- The feature can be deployed and tested by all parties, the development team included. If everyone agrees to move forward, then it can be deployed.
You can’t skip any of those.
If one of the steps “fails”, for example, a review detects a potential issue that lower the value this task is adding, you need to go back to the beginning.
So be strong! Resist the temptation to hack your way!
References:
https://www.targetprocess.com/articles/speed-in-software-development/
https://thehosk.medium.com/how-we-try-to-speed-up-it-projects-and-why-it-doesnt-work-ca3bdc5d7413
