You have heard of TDD, BDD, DDD and DDD (I know I said DDD twice. One is Document Driven Development (never heard of that before 5 minutes ago) and Domain Driven Development).
I present to you, Stress Driven Development (SDD), how software is written in a successful tech company near you.
Introduction
In the chaotic realm of software development, where deadlines morph into nightmares and stakeholders summon results like wizards casting spells, developers are often thrown into a whirlwind of tasks and issues. But let's set aside the predictable ways of task prioritisation for a moment and journey into the realm of absurdity: Stress Driven Development (SDD).
What is Stress Driven Development?
Picture this: developers hurrying through the office, phone lines buzzing, and the coffee machine working overtime. This, my friend, is the theatre of Stress Driven Development (SDD). Unlike the typical approaches to task prioritisation, SDD thrives on the sheer panic and frenzy expressed by the ones reporting the issues. It’s like the emergency room, but with code.
And don't forget, for the ultimate SDD experience, remote won't work. It must be served on-site, in-office, and preferably accompanied by a passionate monologue delivered right in your face. At the very least via phone call.
The Rules of SDD
Volume of Complaints Matters: In the realm of SDD, the louder the complaints, the higher the task jumps up the priority ladder. Because clearly, if someone's yelling or crying about it, it must be super critical and important to the health of the entire business.
Job Titles Influence Priority: In the wild world of SDD, your job title is your sword. If a higher-up waltzes in and utters the sacred words, "This needs fixing!", the developers bow in reverence, and the issue rockets to the top of the crisis list. After all, titles make for great emergency sirens.
Advantages of SDD
Where There's Panic, There's Progress.
Immediate Attention to Urgent Issues: Thanks to SDD, the office becomes a bustling ER room, and the most melodramatic emergencies take centre stage. Heartbeats rise and developers spring into action like a squad of black belt ninjas.
Aligning with High-Level Priorities: Prioritising tasks based on the urgency expressed by higher-ranking individuals can help align development efforts with broader business goals and objectives.
Optimal Use of Resources: Slow days become gold mines. While there's a lull in the emergency sirens, developers are free to tackle the minor glitches and quirks. Like
- The Peril of Aged Dependency Packages
- Eternally slow Database Response Times
- The Fiasco of Failing Sandbox Environments
- The Legend of Broken Git Branches
- The Haunting Tale of Unreliable Third-Party APIs
- The Enigma of Never-Ending Legacy Code
- The Curse of Mystical Production Bugs
- The Siren Song of Documentation Neglect
You know, inconsequential things like these.
Disadvantages of SDD
Bias in Prioritisation: SDD may inadvertently bias the development process towards those who are more vocal or have higher job titles, potentially overlooking valid concerns from quieter team members.
Lack of Strategic Planning: SDD’s approach to prioritisation can be likened to a game of "Whack-a-Mole" with tasks. While you’re focused on the ones popping up like popcorn, the long-term strategy might just turn into confetti.
Inconsistent Development Pace: The constantly shifting priorities under SDD might lead to an inconsistent development pace, making it difficult to maintain a stable workflow. Making it impossible to set realistic deadlines and meet them.
Conclusion
This approach isn’t as far-fetched as you might think. In the land of endless deadlines and perpetually panicking stakeholders, SDD has a seat at the table.
While we may laugh at the idea of prioritising tasks based on stress levels and job titles, let’s not forget that even in its absurdity, SDD has its moments. It might be chaotic and a tad nonsensical, but hey, it keeps some wheels turning and projects afloat.
So, as we navigate the treacherous waters of software development, it's safe to say that a more balanced and strategic approach is likely to yield more consistent and sustainable results in the world of software development.
But come on. Which business owner, marketer, customer service person (etc) wants that? We all just want our problem solved already.
Top comments (1)
lol this was a fun read. And also a scary one, given how true it seems to be at way too many companies. Even with all the best practices laid out, many folks keep churning away with SDD. It's raw. It's human.
This is why quality leadership is so important.