Headline Driven Development
spakhm.com
spakhm.com
A core part of the Working Backwards idea is to start out by writing a fake press release, even for internal projects. This helps crystallize exactly what is important and what isn't, as it forces you to express your goal precisely and succinctly as well as define what it brings to the table.
[1] https://youtu.be/aFdpBqmDpzM?si=NFM9N62VpWmRi8Jp
[2] https://www.amazon.com/Working-Backwards-Insights-Stories-Se...
The author is the founder of the now-defunct YC startup RethinkDB. He learned engineering management the hard way, and he has done a lot of writing in various places that resembles this one: they’re un-nuanced bits of advice that take a strong position. I wouldn’t be surprised if the author actually stands by each of them, but he surely is well aware that this isn't mainstream “best practice” material. After all, that would be boring. We can find an endless stream of that on LinkedIn.
Personally I find it refreshing. Too much software engineering management advice is so overly nuanced and thinned down that nobody is offended but nobody learns anything either.
A lot of the author’s articles and tweets contain a way of looking at things that I hadn’t previously considered. I don’t think you need to agree with the whole thing to take whatever part out of it that resonates. And, well, they’re ultra-fast reads.
(In this particular case, I love the headline part, I think it can help us cut away stuff that seems important but isn’t. I hate the deadline part because I think arbitrary deadlines and constant crunch mode are bad. I don’t think spakhm minds that I only appreciate half of it)
I love and bask in simplicity, but I think the reasons software engineering management advice is often overly nuanced is that it is a very complicated subject where simple approaches don't work. The number of corner cases that emerge are staggering. The most "simple" advice I would give now is that you need to know your people. Personalities and individual working styles make one strategy work great on one team and terrible on the other, and it's not as simple as the first team being good and the second one being bad.
There are now only two articles presently live on his site; all past ones are 404.
“Limit WIP” is a well-known recommendation in agile circles. It’s great except for the situations where it doesn’t work, eg. you have multiple customers with must-do features, you have support commitments and bugs to fix, your work doesn’t cleanly divide into [team size] pieces, etc.
But particularly for small teams pre-PMF it is good directional advice, as folks seem to err on the side of trying to do too much in parallel. And even if you don’t _actually_ only work on one headline, having exec buy in for the general approach is great for focus.
This is exactly where you want to limit work in progress and have your management or leadership earn the big bucks by managing your multiple customers with must-do features expectations.
The way you get work to done is to focus on getting it done, not adding more work. Limited work in progress doesn't mean they can't be parallel efforts and most teams do that. It means that we figure out how much the team can do at once before it slows work delivery down and stick to that. Nothing is exact so some leeway is expected.
Kanban does have the possibility of expediting bug fixes or other work disrupting priorities, but it does mean that other work is done later and that needs to be managed by leadership with your customers and stakeholders.
When you’re building your own thing it’s easy to get carried away and spend too much time on increasingly granular details and endless scope creep. It’s not easy to keep it lean and actually get your product launched and in front of customers quickly.
The article’s approach - which should probably not be taken too literally in some cases - gets you to keep the end goal in mind. And the end goal of software development is almost always a business goal and not a technical one. Something else that’s often easy to lose sight of as a developer.
https://www.businessinsider.com/heres-the-surprising-way-ama...
https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
A former employee tweeted [1] shortly after that "Having worked at Tesla, I can say with some confidence that the design engineers are hearing about this requirement for the first time here".
[1] https://twitter.com/Superfast/status/1575591147828744192
Let's just skip over the part of the story where VirnetX sued them for patent infringement, won the first case on appeal [1], lost a second related case regarding VPN patents [2], and then seemingly vanished into thin air.
[1] https://www.reuters.com/article/idUSW1N27H05F/
[2] https://www.reuters.com/legal/apple-wins-us-appeal-over-pate...
I reject the deadline part (I'm a solo dev, I do what I want when I want), but I love the idea of focusing on working on discrete functionality that I can then communicate to my small community of followers to show progress.
But as someone who often works solo or in a very small team, it's obvious that I need to pick the next most important thing and just work on that.
It's also clear to me that I don't want an issue tracker or even any separate place to put tasks. Because what happens is then they pile on a bunch of tasks that are lower priority which I have to keep trying to explain that I am ignoring them for now since there are higher priorities.
What I prefer is to just have a single text chat channel and a live deployment of the software that updates every few days or week. Then we decide whatever the best priority is and work on that.
Having a separate place to put issues and requests encourages indirect communication and creating backlogs that don't add business value and just stress the developers out.
This depends a lot on what your team is like and what your long term vs short term look like.
If you've got an established product and revenue stream and can look 5 years ahead then pushing deadlines will make developers cut corners and make feature delivery a lot slower and buggier a couple of years down the line.
And if you have a motivated hardworking team (which, to be fair, isn't that common) you won't get much of an increase in pace as the deadline approaches, you'll just get more corner cutting and short termism.
Headlines are good but not a replacement for long term thinking. The devs debating how to meet the next 3 years goals is still valuable and those insights can lead to better ordering, flushing out crap that ain’t really needed and architecture in general.
For example those discussion might lead you to choose kubernetes or avoid it. I don’t think headlines alone get you there. Also things like what teams to have, what roles to hire etc.
Headlines (Aka… user story “epics”? OKR objectives?) are a good tool though.
On one hand, this could easily be read as the musings of some overzealous, re-awakened and re-charged techbro/middle-manager who has tried and failed a few times. But this time, things are gonna be different....
But also, there's a modicum of truth in there. Only the experienced will recognize the red flags buried in the brush-away commentary.
My colleagues use RDD and MDD:
RDD -> Resume Driven Development
MDD -> Medium.com Driven Development
Damn fashion show this shit.
SOS - Shiny Object Syndrome
MDD - Magpie Driven Development
HDD - Hype Driven Development
JDD - Jargon Driven Development
BWDD - BuzzWords Driven Development
HNDD - Hacker News Driven Development
RDD - Resume Driven Development
CVDD - CV Driven Development
EDD - Epoch Driven Development
PDD - Promotion Driven Development
BPDD - Blog Post Driven Development
MDD - Medium.com Driven Development
HDD - Headline Driven DevelopmentNDDCDD - Noun driven development categorisation driven development
LOL, no.
Just because you lay something out simply doesnt mean youve simplified something.
Here's a simple statement:
"Do the most important work, and ignore everything else"
Do you see the problems with that statement? If not I cannot help you. If so then you probably agree with me already.
This is not an article boiling something complicated down to it's essential bits. This is just any old "focus" advice devoid of any real world details, that falls apart as soon as you try it.
On the other hand, I love it. If you can’t work backwards from a great headline… what exactly are we building again???
Also it’s April 1 so haha, good timing if it’s one of those :p
I don't agree with it but I can see how somebody who only cares about getting rich by any means necessary would be interested in this approach.
Please no. I keep working at places where management gets this idea that all developers work better under pressure, and make arbitrary deadlines because of that. It's an awful way to work, especially for an extended period of time.
> pick an aggressive date to ship the first headline
From the way I've seen this done, the headline is too big (despite the article calling out a realistic example) and the timeline is too aggressive (not addressed at all). Maybe it's fine for a startup or small org where things can be ignored, but I've got lights to keep on and users to support, and "work like hell on this and only this" doesn't really fly, or if it's the actual expectation, is awful.
Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. This is a nightmare, because you end up working long hours on valueless work… and upset all your stakeholders by ignoring their urgent requests to deliver small fixes and enhancements to instead just do the one thing you said you would, even though it ends up being worthless.
Honestly, I don’t see why a variation of this wouldn’t work. It’s like a headline is a sprint goal or an epic or whatever agile artifact you choose… You can still apply good engineering practices from there on: splitting the work into smaller bills, working against a solid definition-of-done, testing rigorously, etc.
I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff.
After all, look at the example headlines:
“You can now rent VMs through an API”,
“we rolled out FSD autopilot”,
“Treasury is available in India”.
Those are all goals!
"Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier. I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business.
No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high.
[1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
> Headlines are so non-specific that you could “deliver” a headline that could easily not really meet a customer need. I don't think so - the headline is simply the goal. If the goal is not "Customer will buy this" then your headline is simply fluff.
[JO: I don't understand what you mean here. Are you saying the goals should all be appended with "and the customer buys it?" So, "You can now rent VMS through and API, and customers do?" In which case, wouldn't that be something that has to happen over time and cannot be delivered solely by engineering by an arbitrary date?]
After all, look at the example headlines:
“You can now rent VMs through an API”,
“we rolled out FSD autopilot”,
“Treasury is available in India”.
Those are all goals!
[JO:I agree that they are all goals. My assumption though is that just reaching those goals is not sufficient for success.
If you goal is "customer can now rent VMs through an API", my assumption is that to meet that initial goal a MVP will be delivered. My further assumption is that the MVP will not have all the features it will ultimately need to be commercially successful and so will need to be iterated on to be better than the alternatives customers have available to them. So, devoting engineering resources to the next headline and not iterating and improving the MVP would be a mistake. If you keep doing that, you end up with a bunch of half-baked marginal products, none of which is successful.]
"Urgent"[1] requests to deliver small fixes don't, ultimately, matter to business, both provider and supplier.
[JO: I disagree. In the B2B setting at least, I've seen customers cancel because commitments to make minor enhancements for them were not honored. It is rare but it does happen. In addition, while customers rarely cite a specific bug as the reason to cancel, they often cite things like "bad UI" or "bad usability" or "lack of adoption", which IMHO is sometimes the way that customers articulate their experience and/or the results of working with a buggy product.]
I've never seen business switch software because of bugs. If that was the case, Windows would never have gained the foothold it had over business.
[JO: Can you tell me more about what you are thinking about here? In general, I think Microsoft is a tricky example to use, because they have something of a "natural monopoly", and unless you happen to be working at another company that also has such a natural monopoly, an example based off Microsoft may not be applicable.]
No business drops their existing system because it occasionally eats some data, resets everyone's session, or similar. The cost to switch to a competitor is simply too high.
[JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
[1] As a long-time veteran of software development (25 years), all customers prioritise all their reports "urgent or higher".
[JO: On that we agree; one of my engineering colleagues used to say, if you say everything is urgent, you are letting the other person decide the priority. A good PM should run interference between such customer requests to provide useful and realistic prioritization, otherwise there is no-prioritization at all.]
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
I agree with this (and the clarification in the paragraph just after this), but to my mind, those are different goals.
The goal of an MVP is quite different to the goal of refinement - in one you are determining if there is a market, in the other you are determining PMF via successive refinements.
Those would be different headlines, but headlines nonetheless. I see it as H1: "You can now rent VMs through an API" H2: "Rentable VMs available across our entire offering (not just the x2.small)" H3: "Cost-calculator available on our RVMs" H4: "RVM snapshot facility, first of its kind, now available" H5: "RVMs are transferrable between regions with no loss of data"
What you clarify was not something I considered - that each new headline one is working towards is, in fact, a new product. I only considered headline-oriented work in the context of a single product.
I think working towards a headline is a bad idea if the headline is a greenfield development, but a good idea when ensuring that the product is evolving to ideally fit the demands of the market.
[JO: Yeah, that makes sense. I can see that in the context of a single product. The examples the OP provided made me think of the headlines as being more mercurial and greenfield in scope, but that was an assumption.]
> [JO: I disagree. Not all existing systems have so high switching costs that customers will tolerate the system losing data.]
What systems are you thinking off? I've seen ancient tiny MSDOS-based software used well into the late 2000s in spite of poor reliability of the underlying system. I've seen long-lived ERP systems have their bugs worked around by users over a decade.
[JO: That specific example that came to mind was a GRC system which I worked on years ago. The system was full of bugs, and a large insurance carrier wanted an enhancement. I forget just now what the specific enhancement request was. I do remember though that when I said "no", they said "Ok, then we are not renewing our subscription." I remember it vividly because I was surprised, that was the first time it had happened to me.]
I mean, right now I consulted on a small company extremely unhappy with their accounting software (quickbooks force-moving everyone to their cloud)) dismiss any notion of using anything else because "The users already know how to use this!"
[JO: Yeah, that can be a problem sometimes.]
[EDIT: I only somewhat agree with your points, but I upvoted your comment anyway because the ones I agree with, I feel are good points].
[JO: Thanks!]
In practice, this never made sense on my previous agile team. Features were never the perfect size and divisible in such a way we could all work towards a unified goal. Plus, QA can't work until we're done.