Nick Floyd
He looked at his cursor in vim, his code editor of choice, as if it was going to write the code for him. Jake was an average guy, inspired developer, lover of coffee and JavaScript. Pragmatism seemed to be part of his DNA. Today he felt like he was throwing all of that out the window.
Earlier that week one of the executives, a "C"-something, got beat up on Twitter about a competitor's feature set. Usually the executive would just acknowledge the harsh comment and thank the person for their time and thoughts. He might even make a note if it was something he deemed valuable; but today was different.
Crashing through the narrow entry way of Jake's office, in a Kramer-like fashion, Cameron, the CTO had an intensity that both inspired and confused Jake. He began barking, with an intelligible tone.
Cameron, pointing at a printout of a tweet (because executives print out that sort of thing), "We've got to do something about this!"
Jake shrugging, "About what?"
"We don't support 'export to pdf' from our doc product and these other 6 competitors do!" Cameron replied.
That's when Jake knew it. He had been a developer long enough to know when he and his team were about to be asked to consciously add "rust" to their software. They called it rust because it was technical debt. He knew that these nasty bits of code that get added either knowingly or unwittingly would generate problems and holes in the source overtime. These are things that he and the team were ashamed of but still tried to defend for whatever innate need a developer has to justify their bad choices.
Jake knew the "Technical Debt Quadrant" well. "The words "deliberate" or "inadvertent" would run through his mind after shipping something. He knew this time it would be "deliberate." He also knew that he and his team would be asked to deliberately choose reckless engineering practices, forgo testing, and build something that would require a huge amount of effort in a small amount of time. Finally, he acknowledged that the state of the current code already had rust all over it; a veritable case study for the idea of "interest payments" from technical debt.
Jake sheepishly hung his head low and simply said, "ok, we'll get started right away."
Grappling with the fact that the team wouldn't get to embrace decent engineering practices such as TDD - Test Driven Development or clean iteration cycles they were constantly fighting off feeling regret over taking on the project. "This project 'smells' and 'tastes' like regret, " Jake thought.
Initially the project seemed to be going really well, despite how it "tasted." The team provided short bursts of effort on the disorganized project plan they were given. The product team was dealing with just as much uncertainty as the development team. "Push through," they thought, "this has got to work!" Though, if you asked any of them they really didn't know why they were doing what they were doing. Lack of vision and knee-jerk decisions tend to muddy the creative pool and hurt morale.
Then the proverbial wheels flew off of the project scope first.
Lack of planning and clarity of goals finally made the project buckle. Any engineer worth his or her salt knows loose scope is scope that grows and creeps like a monster under your bed waiting to grab at your ankle and pull you under. No fun, no good.
Constant collisions with concepts and project scope changes made for a miserable experience as well. Lack of focus and a blurred vision made rolling with these changes difficult and daunting - no one seemed to know where things were or even where they were heading.
In the coming weeks Jake and the team pushed on, running into merge issues because other teams, ironically, were refactoring the same area of the code that they were working in to try to pay down some of that technical debt. They ran into massive regressions for the same reasons - code collisions and rust.
"Rust, rust, rust!", Jake thought as he stared at his console. He simply ran out of mental capital; he could type no more or even think clearly. He had to stop a project that was almost finished to work on this "trash fire" of a project using another kind of TDD - Tweet Driven Development.
He regretted every new line he wrote. He even hated solving that complex serialization issue which was a critical stepping stone to them supporting the export to PDF feature. This reasonable engineer had not written one single test for any of the code he had committed and most of the lines and method bodies had lint rule overrides to ignore the engineering styling rules that he helped put in place a year before. He was a shadow of the engineer that he once was.
Jake had heard about this type of "fade" happening to some engineers in the gaming industry but had never experienced it himself. "What happened?", he puzzled. In that moment he saw a note he took while talking to a mentor years ago...
"'No' is your most powerful tool in your belt, use it often before you find yourself needing more tools and more time to fix something 'no' could've fixed for you."
See practical applications in my friend Kirby's Technical debt and the lies we tell ourselves
Title image courtesy of Berry Pousman via flickr