Software developers constantly make trade-offs. Picking an opinionated framework speeds up delivery, but makes it harder to build non-conventional features. Larger payloads vs multiple requests. Does this project benefit from NoSQL?
Devs are pretty good at handling pros vs cons. At least, when it comes to their own slice of control. It gets uneasy when handling other people’s trade-offs.
Should we skip refactoring if that means we can release in time for the trade show? That upload-by-Excel is going to be a horrible mess, but it’s what the “Business” wants.
Developers typically fall somewhere on the “pragmatism scale”.
On the one hand of the spectrum, there are the Hackers. You know the kind. They’ll build whatever is asked as quickly as possible. If it works, it works. Until it doesn’t. Companies love Hackers.
On the other hand, there are the Clean Code Zealots. They are never happy with the state of the code. They’ll keep moving abstraction layers around and will rewrite perfectly fine code to fit some Functional Programming dream. Companies hate Zealots.
The first group gets everything done until it stops working. The second group keeps working on something that’s never gonna get done.
Fortunately, most developers fall in that middle ground and they pride themselves on being pragmatic. They’ll block certain horrors and let other stuff slide. Companies appreciate pragmatic software developers.
There are some major downsides to being pragmatic, though.
Entropy
Keeping code clean requires so much effort, that inevitably we’re going to fail. The more pragmatic we are, the faster the code base is going to suffer. In the long run, we all become Hackers. It’s just a matter of time.
Expectations
Business people adore Hackers. They get stuff done. Software quality is never a concern until it is. By being pragmatic, you’re setting up the expectation of fast, no-hassle results. It will get more difficult to justify reworking certain components. Feature X was similar and that only took half the time!
Software developers love helping people. Their instinct is to build that hotly anticipated feature as fast as possible. So how can you be pragmatic about being pragmatic?
Design the perfect solution
Often, there will not be room to build the ideal solution, but we must design it anyway. When a feature is requested, design it the way a Zealot would. That ideal feature is going to be the benchmark to measure our implementation against.
Negotiate hard
If we can’t build the ideal feature, we’ll need to settle down. That doesn’t mean devs should throw their hands up and start hacking. Sit down with your stakeholders and negotiate a compromise. They must give up stuff. There should be a penalty for not building the ideal solution. That’s not a power play, but an insurance. The technical pain is invisible to Business people. There needs to be a functional trade-off to signal that the ideal solution is not “done”.
Be vocal
If you can’t negotiate a functional trade-off, then explain to your stakeholders that you’re taking a shortcut and why it’s a shortcut. Make sure nobody can weasel out. Create a critical bug ticket for every shortcut. Make sure that it’s reported in the Go/No Go meetings.
Again: Business adores Hackers and when you say “technical debt” they hear “Done”. Keep the crap on the radar.
Being a pragmatic software developer is walking a tightrope between Hacker and Zealot. You’re going to fall off eventually. Inevitably, you’re going to let something slide that should have been flagged.
That’s OK.
Pick it up and put it back on the radar.