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.
