How to Be a Responsible Developer
Not long ago, I wrote on how to be awesome and not be a jerk. A month or so before that, I wrote on the minimal docs that should be a part of a project. There’s a trend here, I admit, though it wasn’t very intentional up front, but in our latest JS UI library crazed world, maybe more of us need to be speaking up for how to be responsible professionals?
Today I’d like to dwell on this concept —a few aspects of being a “responsible” developer. Now, I might get shouted down by consultants, because how they make money is often coming in and cleaning up after sloppy work (to put it bluntly), but I’ll take that risk. :)
A False Dichotomy — Ship Fast vs. “Clean Code”
While there is absolutely no doubt that even highly intelligent, seasoned software developers can fall into the trap of over designing something, focusing on edge cases too much, gold plating, pre-optimizing, etc., one should never generalize that possibility into a notion that being thoughtful about solution design (before jumping into coding), taking time to execute on well-known industry good (best) practices, and just generally giving thought for the future maintainability of a solution is somehow contradictory to shipping in a timely manner.
You’ll note that I use the word “timely.” That’s very intentional, because people like to talk about “shipping fast” as if it’s a virtue. In my experience, “fast” tends to mean “tripping over yourself to make something work and getting it out the door (usually with minimal if any testing).” “Fast” tends to become a frenetic philosophy that ironically leads to exactly its opposite. Assuming the software survives in the market despite the increased bugginess that goes along with the “fast” mentality, being “fast” tends to lead to the accumulation of technical debt that makes it ever more difficult to move fast.
“Fast” tends to become a frenetic philosophy that ironically leads to exactly its opposite.
“Fast” means always preferring tactical, heat of the moment “best” choices over strategic, considerate choices that take more time to ponder. “Fast” significantly increases the likelihood that you will look back on a decision and have to shrug and say “it seemed like a good idea at the time,” while trying to figure out now, with far more technical forces fighting against you, how to get yourself out of that bad decision that seemed like a good idea at the time. And at the end of the day “fast” is usually a very ill-defined concept that is mainly used as a rhetorical bludgeon — either by management or fellow developers — to coerce thoughtful people to act against their better judgment.
“Timely,” on the other hand, suggests moving at a pace that is appropriate considering the problems being solved. Every product/business person ever wants what they want yesterday. Essentially as soon as they think of it, they want it done. Every second after their decision to move ahead on what they dream up is a “delay” in their heads. Every day that something is not shipped, we are not making (or saving) money, and not only that, we are spending it on you, Mr. Developer. So yeah, they’re gonna push and push and push. Even the best product people I’ve worked with (and I’ve been on the product side, too) will do that. And honestly, to some degree, that is their job.
As Responsible Developers, we ought not to just mindlessly give in to the business’ sense of urgency.
But as Responsible Developers, we ought not to just mindlessly give in to that sense of urgency. We don’t need to adopt fast-as-hell as our credo. It’s our duty to the business to engage in the uncomfortable potential of seeming like we’re being slow. Obviously, I’m not talking about being slow for the sake of being slow but rather being slow enough to do our job right.
“Timely” means that we take the time to understand the problems (ideally with the help of UX/Design research); it means we take the time to understand and appreciate the business pressures. And then we factor those things into how we design our solutions. The plans and designs (and resultant estimates) we come up with should include not only the sense of urgency, not only the sense of best design, but also a sense of reliability (“it should just work, and keep working”) and a sense of maintainability (“we shouldn’t shoot our future selves in the foot”). We developers are the ones who know best when it comes to those last two things, and it’s our job to push back if need be to ensure they are realized.
At the same time, we gotta fight our natural tendency over analyze things, to solve ALL THE THINGS, and to hedge our bets. That’s the other side of “timely.” I was recently blathering about an “ownership mentality,” which basically means acting as if the business we are working for were our business, i.e., that we are the business/product folks. Put more generally, this mentality means putting ourselves in their shoes and behaving as we would want our devs to behave. It takes cultivating, but it’s important and part of being Responsible Developers.
So “timely” means cultivating a reasonable sense of urgency while at the same time not falling into the trap of Anxiety Driven Development, that is, we need to ensure we are still doing the right things — the things that promote reliability and maintainability. “On time” doesn’t mean some random date we pull out of our asses. It means a date that delivers meaningful value when it will still be valuable while also ensuring that the shit doesn’t hit the fan due to rushing stuff out and that when “the next big thing” is asked for, we have laid the groundwork so that we can deliver it, as well, in a timely fashion.
The Dumbest Thing I’ve Ever Heard in Software
Believe it or not, I’ve heard “clean code” used like it’s a bad word, contraposed to “shipping,” as if the two are mutually exclusive. It seems to come from some kind of “too cool for school” mentality — taking jibes at all these old fogies who don’t know how to ship software…
“Make code that’s easy to throw away.” ← Quite possibly the dumbest thing I’ve ever heard in software. I mean, unless you are specifically talking about prototyping, where it couldn’t be truer as a guiding principle. But no, this is talking about productional code. This seems to have become a “thing” nowadays in the JavaScript space. On the one hand, I can sort of not fault us for feeling that way — because the pace of change on the Web/JS space is mind-numbingly fast. Even the best-written code has a higher-than-average chance of being somehow outdated in just a year or two.
On the other hand, nobody can afford to completely rewrite an app of any significant complexity (i.e., any significant business value) every few years, despite much of the underlying tech becoming outmoded that quickly, if not sooner. Many software solutions take that long just to get to a stable sweet spot of having figured out enough of the right functionality to hit the 80% usage/business cases. And even on mature solutions — especially on mature solutions — there is always a hugantic backlog of features, great and small, that customers are ever advocating for. On top of that, there are always new, big ideas that need to be done to battle the competition and continue to win in ever-changing markets. Acting as if “we can always just throw it away and rewrite it” is about the most naive, unprofessional, and irresponsible approach to making software that I can imagine.
Acting as if “we can always just throw it away and rewrite it” is about the most naive, unprofessional, and irresponsible approach to making software that I can imagine.
So the technology tools are gonna change. Who cares?! We have software still driving big business that was written in the 70s (probably before!). Is it still there because people don’t think it’d be nice to update it? No. Is it still there just because it was written with “Clean Code” in mind? No — clean code, as such, wasn’t even a thing then. That software is still there because it is battle tested, because it sufficiently meets a need, and often because it would be too costly to replace.
Note that the costliness to replace has nothing to do with the coding practices that the original authors used; sloppy or clean, it’s a sunk cost. The costliness that prevents rewrites has to do with the actual cost — not to mention the risk — of having developers rewrite it today, again regardless of “shipping fast” or “clean coding.” Often, if it ain’t broke, don’t fix it rules the day, regardless of the development philosophy used to produce it — and that’s why we should err on the side of assuming our code will live on indefinitely and can’t be just thrown away.
The actual reality is that, more often than not, code lives on well beyond how long the authors thought it would live. As an industry, we’ve recognized this for a long time, and that’s why we have developed patterns, principles, and practices that help us to prepare for this reality. What I hear when people say things like the above is basically one of two things (or maybe a bit of both):
- I know better than all the experienced folks who’ve come before me in this industry. My (usually) 1–7 years of individual, isolated experience trumps the accumulated wisdom of our industry.
- I don’t really understand our industry’s patterns and best practices and don’t feel like taking the time to learn from other (often more experienced) software developers. So I’ll just wing it. It’s far more important to spend my time learning the latest development in my favorite JS framework or keep up on the latest Web standards proposal.
In other words, it’s youthful thinking, which is maybe not so surprising when you consider the median age of software developers. Yeah, okay, now I sound like “get off my lawn!” So be it. On the other hand, those of us who are old enough just maybe have been around long enough to see the need for and importance of being a Responsible Developer, Clean Coder, Craftsman, or whatever your preferred nomenclature. (And heck, I’m still comparatively young to a lot of the more senior folks in our industry!)
It’s fine that we want to keep reinventing the wheel. It’s fine that we’re gonna keep trying and trying to make ever better and newer frameworks and tools. It’s awesome that we’re trying to make software that prioritizes great UX. It’s exciting that things are moving and changing so fast. And it’s inevitable that business always needs things done yesterday.
But none of that means we need to, much less should we, sacrifice our hard-earned collective wisdom that transcends all these particular technological and business situations, that wisdom that guides us on how to responsibly make reliable, maintainable software. So let’s take a deep breath, keep the bigger picture in view, and leverage all of that as we deliver software in a timely, rather than rushed/fast, manner.
