Headline Driven Development

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.

atombender• 2 years ago

This is just Amazon's "Working Backwards" methodology [1] expressed simplistically. There's also a book about written by key Amazon people. [2]

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...

dgb23• 2 years ago

Also README driven development seems similar, with a different target audience.

stanac• 2 years ago

That's what I do when writing libraries, now I have a name for it.

oytis• 2 years ago

I've seen this idea in Tony Fadell's Build, didn't know it was Amazon thing.

cjk2• 2 years ago

Very funny but perhaps I wish it wasn't.

My colleagues use RDD and MDD:

RDD -> Resume Driven Development

MDD -> Medium.com Driven Development

Damn fashion show this shit.

nivertech• 2 years ago

Full list:

    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 Development

stuartjohnson12• 2 years ago

Let us not forget the most important driver:

NDDCDD - Noun driven development categorisation driven development

majikandy• 2 years ago

I was once told mdd was mortgage driven development. Make code as confusing as hell so to they keep you on and you can keep paying your mortgage.

pixl97• 2 years ago

Simulacrum driven development

yellow_lead• 2 years ago

Although it's a joke, I'm reminded of "Sprint goals" from agile.

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.

pydry• 2 years ago

Isnt sprint goals just "do all the tickets"?

Veuxdo• 2 years ago

Reverse it. The goals should point to what tickets to do.

MrBuddyCasino• 2 years ago

Sprint goals are usually post-hoc: everybody tries to come up with an umbrella term after the tickets have been refined & selected.

paradite• 2 years ago

This is formalized as having a press release at the start of PRD in product management.

Shrezzing• 2 years ago

It reminds me of Musk announcing that the Cybertruck would be able to traverse calm water as a small boat.

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

chrisfinazzo• 2 years ago

See also: Steve Jobs' announcement that FaceTime would be an open protocol. To a large extent, both Engineering and Legal didn't think it was something they would need to do, and as such, didn't plan for it.

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...

rokob• 2 years ago

Can’t tell if April Fools joke or not because I know places like this and it’s a nightmare way to build software.

CaptainOfCoit• 2 years ago

Want to expand on exactly why it is a nightmare? Core idea seems to be about focus: decide one thing, "work like hell" to do that thing, then move on to the next thing.

eddieroger• 2 years ago

In my experience, this part:

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.

ghaff3• 2 years ago

Any reasonable idea can be taken to an extreme but some variant of "keep your focus on your key goals" doesn't seem unreasonable to me.

drngdds• 2 years ago

Working like hell to meet an arbitrary deadline at all costs is a nightmare

baxtr2• 2 years ago

How come it’s a nightmare at these places?

johnobrien10103• 2 years ago

This is a joke, and the reason why is because even if you “deliver” a headline, you are unlikely to be “done”. It runs counter to the approach of incrementally shipping functionality, listening to feedback, and adjusting.

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.

onionisafruit• 2 years ago

I’m not sure either. The subject matter and article date scream April Fools, but the article doesn’t yuck it up with increasingly ridiculous examples.

Heloseaa• 2 years ago

Can't this be qualified more simply as the Parkinson's law in action ?

ghaff3• 2 years ago

There's definitely truth to that as the flip side. If you say something will take three years, you'll find some way to stretch it out to three years (or at least 2 1/2) even if you could have gotten something reasonable out in a year.

tailspin2019• 2 years ago

As someone currently working hard on a simple MVP for my own SaaS product, this is good advice for me.

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.

stevage• 2 years ago

It probably is actually good advice for a sole developer.

liampulles• 2 years ago

There is a similar thing to this which I use for side projects all the time:

https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

nunez• 2 years ago

I've been developing my side projects like this for a while. I didn't know it had a name!

Trasmatta• 2 years ago

Third, the deadline effect is real. Most of the work in college happens at midnight before the project is due. The industry isn’t that different. So simulating class assignments turns out to be a very effective way to ship quickly. You need a discrete chunk of work, with an arbitrary deadline2, and a binary outcome. You get this with headlines– a headline has either shipped by a given timestamp or it hasn’t.

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.

HumblyTossed• 2 years ago

Agree. And one reason devs work better under pressure is because of analysis paralysis. Have a structure in place to minimize this and you don't need to work devs under pressure.

richrichie• 2 years ago

Most of the work in college happens at midnight before the project is due. The industry isn’t that different.

LOL, no.

ergonaught2• 2 years ago

Many replies are so busy finding reasons to reject an entirely sound premise that they deliberately overlook "Don’t work on anything that doesn’t help you ship the headline", which clearly implies that you do work on the things which actually help ship the headline, ie: all of the "but what abouts" in the torrent of picked nits.

jroseattle• 2 years ago

As April Fools jokes go, this is really well done.

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.

concordDance• 2 years ago

Third, the deadline effect is real. Most of the work in college happens at midnight before the project is due.

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.

podgorniy• 2 years ago

This is a beautiful conceptualisation of the modern-day incentives

buro9• 2 years ago

Well this is, at least, better than Gartner Driven Development which has been observed at several startups. Whereby a startup begins to care about their placement on the Magic Quadrant, and start adding very poor imitations of features merely to get a check on a form and move their company more towards the top-right "Leaders" category.

AdamProut• 2 years ago

I'm not sure why you're getting downvoted. I think the pressure to appease Gartner usually starts when companies bring in CEOs whose primary background is enterprise sales. They tend to over value magic quadrant positioning (in my view).

ghaff3• 2 years ago

For enterprise sales, the Gartner MQ and Forrester Wave are pretty big deals. (As is how they talk about you in client inquiries generally.) Maybe enterprise buyers place more stock in how the big analyst firms view a vendor than they should but it's generally the reality.

skrebbel• 2 years ago

As there seems to be some doubt as to whether this is a joke or not, I’d like to posit that we’re not supposed to know and that’s the point.

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)

freedomben• 2 years ago

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.

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.

Ginger-Pickles• 2 years ago

This author, discussed previously: https://news.ycombinator.com/from?site=spakhm.com

There are now only two articles presently live on his site; all past ones are 404.

corytheboyd• 2 years ago

Obviously a bit too simple, as if you don’t focus on at least some platform maintainability it’s all going to shit around headline 10, where each new headline release INEXPLICABLYYYYY introduces more and more bugs.

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

bdw5204• 2 years ago

This has to be a joke but it's also good advice if you only care about having a minimally viable product to ship by an arbitrary date. A strategy of "cut as many corners as possible and do the bare minimum" makes money in the short term and hopefully you'll exit before customers figure out that your products are garbage and stop buying them.

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.

banjo-rogue• 2 years ago

Firing our agile consultant has really freed up budget to hire a "headline consultant"!

nickelcitymario• 2 years ago

I don't know if this works in a big organization, but as someone working on a solo project, I actually love it, and don't take it as a joke at all.

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.

irinai13• 2 years ago

I think this is precisely the type of advice that's needed for large organizations. They can easily get mired in all the complexity and managing launches by headlines can (1) simply paint the vision of the future for the teams that are building, (2) simply communicate to leadership what is launching and when so they can a) not block and, better yet b) help unblock and even accelerate.

theptip• 2 years ago

Author rediscovers Kanban and Lean!

“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.

lasereyes136• 2 years ago

“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.

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.

Too• 2 years ago

Isn’t this how Jira works already? Spend lots of effort on writing a ticket description that nobody reads beyond the headline anyway.

ilaksh• 2 years ago

I think the real challenge is for whoever has final word on the goals to have realistic expectations. They almost never really do.

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.

efields• 2 years ago

This is great. It's so simple it hurts.

jimnotgym• 2 years ago

sed -i 's/milestone/headline/g' spakhm.com

from-nibly• 2 years ago

The number of people who are taking this seriously is startling.

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.

Headline Driven Development

Related Stories