Imagine this: You’ve just started working on a new team and you’ve your first task, a simple bug fix to address a problem recently experienced by multiple customers. After pulling the code down onto your development machine, you’ve opened it in for the first time and you can’t quite believe what you’re seeing on screen in front of you.

The code is bad. Everywhere you look, you see problems. Local variables with misleading names, functions that run to thousands of lines of code, business logic squirreled away in the data access layer, injection related security flaws, the list goes on and on.

Before you know it, you’ve deployed your weapons grade vocabulary and your onboarding buddy has started to wonder if you have an undisclosed mental health issue.

Profanity Driven Development occurs when there is a dramatic disconnect between the reality of code you’re reading and the expectations you brought to the table.

While it can be tempting to dismiss all who went before as incompetent jerks who should have their keyboard privileges revoked, perhaps it would be wise to take a step back and take a breath.

I’ve found that there’s an almost universally applicable answer for why dodgy code looks the way it does: History.

Perhaps a summer intern wrote this this code, and they finished up last week to start the second year of their Information Management undergraduate degree. An intern who didn’t have the experience to know any better, and who wrote the best code they could.

Perhaps this code was by the company founder written five years ago, and it’s worked well enough all that time that no one has needed to address any bugs. It might be that your eyes are the first ones to recognize that there are some issues to address.

Or perhaps the company desperately needed to release the first version of their product for the annual industry trade show last month, knowing that the fate of the entire company was at stake. The development team may knowingly cut some corners with the intention of circling back to tidy things up later, and maybe that’s why you’ve joined the team.

Before you start cursing those who went before, find out what they were doing and why they did things that way. You might find out some interesting context with which to re-evaluate your opinions. Or you might just find that knowing their names means you can be considerably more fluent and biting with your profanity.


blog comments powered by Disqus
Next Post
Complaint Driven Development (CDD)  15 May 2021
Prior Post
Hype Driven Development (HDD)  17 Apr 2021
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
May 2021