Cowboy Developers, and Requirements

“I don’t need requirements — I know what I’m doing”— #CowboyDeveloper

A paraphrased version of an actual PR-related discussion I had recently follows. And yes, I’ve had this conversation more than once in my career — there are a lot of #TechBros out there .

Hey Bob (let’s just call him Bob), I wanted to talk about this PR you just submitted. Specifically, this bit in the config file — enable_network_console: # Yes | No — care to explain it?¹

Oh, I see, most of the users don’t want the network console, but some might? So you’ve got that in there, just in case anybody wants to enable it?
Cool, cool.
One more question though — why do we even have a network console in the first place? I mean, I was looking at the requirements behind this PR, and I don’t actually see anything about network consoles, let alone enabling/disabling them, y’know?

Oh, right, you thought it might be a useful feature, so you put it in there.
Make sense. And they’re not in the requirements ‘cos the Product Team didn’t think anybody would actually need it.

And there you have it — the punch line. If I had a nickel for every feature that snuck in to the app ‘cos some developer didn’t agree with the product team, well, I’d have a lot of nickels.
The worst part is, there is always an anecdote around that one time when the product team got it wrong, and the feature should have been included, and …, and …, and ….

You know what? The Product Team will always get stuff wrong! Expecting them to get it right the first time is pretty much exactly the same as expecting a developer to get all the code working perfectly the first time! “Agile” isn’t something that happens after the requirements are baked — just like developers iteratively approach perfection (or, heck, GoodEnough-ness), the product team comes up with a set of requirements that they iteratively get feedback on, figuring out what works vs what doesn’t, what should be in there vs what should be removed, what needs to be refined vs what’s good enough…oh, you get the point.
In the meantime, all those #CowboyDevelopers spending valuable time working on stuff that is not part of the product spec are actually increasing the problem surface area for the system, and effectively making everybody else’s life just that much more difficult.

Yes, yes, I know, there are product teams that actually have their heads up their collective behinds. And, equally likely, there are product teams that work harmoniously and seamlessly with engineering with one collective voice and vision. This, however, is for that vast swath in the middle, occupied by those who have an instinctive distrust for both requirements and management. Admit it, you know of — and probably work with! — people like this .

So yeah, the next time you feel like ignoring the product team, and working on that feature that you believe should be in the product, pause, count to 10, and then go talk to the product team about it. And maybe, just maybe, you might want to consider the likelihood that the product folks might actually know what they’re doing. I know, I know, if you’re a #CowboyDeveloper you clearly know better than anybody else, but hey, it’s never too late to learn that you might actually not be all that and a bag of chips…

1. 1. Yes, yes, of course there are no defaults provided. This is a #CowboyDeveloper that we are talking about, y’know?