7 ms·

Headline Driven Development

208 points by MrBuddyCasino 3y ago

anze3db 3y ago
This joke makes some good points.
- tgv 3y ago
  Remarks like "work like hell" and ignoring everybody around you make it stand out for the April 1st joke it is, though.
west0n 3y ago
The Reason Behind "Why Amazon forces its developers to write press releases" https://www.businessinsider.com/heres-the-surprising-way-amazon-decides-what-new-enterprise-products-to-work-on-next-2015-3 https://www.businessinsider.com/heres-the-surprising-way-ama...
timwaagh 3y ago
Is that you boss?
Muromec 3y ago
Ah, the date.
- amadeuspagel 3y ago
  This is the last essay by the same author. Same tone. I think he's serious about this: https://www.spakhm.com/bullshit-ratio https://www.spakhm.com/bullshit-ratio
datascienced 3y ago
This makes sense. Kind of. 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 3y 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 https://youtu.be/aFdpBqmDpzM?si=NFM9N62VpWmRi8Jp [2] https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595 https://www.amazon.com/Working-Backwards-Insights-Stories-Se...
- dgb23 3y ago
  Also README driven development seems similar, with a different target audience.
  - stanac 3y ago
    That's what I do when writing libraries, now I have a name for it.
- oytis 3y ago
  I've seen this idea in Tony Fadell's Build, didn't know it was Amazon thing.
- djangogitit 3y ago
  [dead]
cjk2 3y 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 3y 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 3y ago
    Let us not forget the most important driver: NDDCDD - Noun driven development categorisation driven development
  - majikandy 3y 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 3y ago
  Simulacrum driven development
yellow_lead 3y 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 3y ago
  Isnt sprint goals just "do all the tickets"?
  - Veuxdo 3y ago
    Reverse it. The goals should point to what tickets to do.
- MrBuddyCasino 3y ago
  Sprint goals are usually post-hoc: everybody tries to come up with an umbrella term after the tickets have been refined & selected.
paradite 3y ago
This is formalized as having a press release at the start of PRD in product management.
- Shrezzing 3y 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 https://twitter.com/Superfast/status/1575591147828744192
  - chrisfinazzo 3y 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/ https://www.reuters.com/article/idUSW1N27H05F/ [2] https://www.reuters.com/legal/apple-wins-us-appeal-over-patents-502-mln-virnetx-verdict-2023-03-30/ https://www.reuters.com/legal/apple-wins-us-appeal-over-pate...
rokob 3y 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 3y 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 3y 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.
  - ghaff 3y 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 3y ago
    Working like hell to meet an arbitrary deadline at all costs is a nightmare
- baxtr 3y ago
  How come it’s a nightmare at these places?
  - johnobrien1010 3y 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.
Heloseaa 3y ago
Can't this be qualified more simply as the Parkinson's law in action ?
- ghaff 3y 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 3y 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 3y ago
  It probably is actually good advice for a sole developer.
liampulles 3y 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-development.html https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
- nunez 3y ago
  I've been developing my side projects like this for a while. I didn't know it had a name!
Trasmatta 3y 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 3y 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.
- deleted 3y ago
  [deleted]
richrichie 3y ago
> Most of the work in college happens at midnight before the project is due. The industry isn’t that different. LOL, no.
ergonaught 3y 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 3y 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.
- deleted 3y ago
  [deleted]
concordDance 3y 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 3y ago
This is a beautiful conceptualisation of the modern-day incentives
buro9 3y 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 3y 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).
  - ghaff 3y 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 3y 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 3y 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 3y ago
  This author, discussed previously: https://news.ycombinator.com/from?site=spakhm.com 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 3y 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 3y 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 3y ago
Firing our agile consultant has really freed up budget to hire a "headline consultant"!
nickelcitymario 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
This is great. It's so simple it hurts.
jimnotgym 3y ago
sed -i 's/milestone/headline/g' spakhm.com
from-nibly 3y 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.

208 points by MrBuddyCasino 3y ago

anze3db 3y ago

This joke makes some good points.

tgv 3y ago
Remarks like "work like hell" and ignoring everybody around you make it stand out for the April 1st joke it is, though.

west0n 3y ago

The Reason Behind "Why Amazon forces its developers to write press releases" https://www.businessinsider.com/heres-the-surprising-way-amazon-decides-what-new-enterprise-products-to-work-on-next-2015-3 https://www.businessinsider.com/heres-the-surprising-way-ama...

timwaagh 3y ago

Is that you boss?

Muromec 3y ago

Ah, the date.

amadeuspagel 3y ago
This is the last essay by the same author. Same tone. I think he's serious about this: https://www.spakhm.com/bullshit-ratio https://www.spakhm.com/bullshit-ratio

datascienced 3y ago

This makes sense. Kind of. 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 3y 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 https://youtu.be/aFdpBqmDpzM?si=NFM9N62VpWmRi8Jp [2] https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595 https://www.amazon.com/Working-Backwards-Insights-Stories-Se...

dgb23 3y ago
Also README driven development seems similar, with a different target audience.
- stanac 3y ago
  That's what I do when writing libraries, now I have a name for it.
oytis 3y ago
I've seen this idea in Tony Fadell's Build, didn't know it was Amazon thing.
djangogitit 3y ago
[dead]

cjk2 3y 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 3y 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 3y ago
  Let us not forget the most important driver: NDDCDD - Noun driven development categorisation driven development
- majikandy 3y 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 3y ago
Simulacrum driven development

yellow_lead 3y 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 3y ago
Isnt sprint goals just "do all the tickets"?
- Veuxdo 3y ago
  Reverse it. The goals should point to what tickets to do.
MrBuddyCasino 3y ago
Sprint goals are usually post-hoc: everybody tries to come up with an umbrella term after the tickets have been refined & selected.

paradite 3y ago

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

Shrezzing 3y 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 https://twitter.com/Superfast/status/1575591147828744192
- chrisfinazzo 3y 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/ https://www.reuters.com/article/idUSW1N27H05F/ [2] https://www.reuters.com/legal/apple-wins-us-appeal-over-patents-502-mln-virnetx-verdict-2023-03-30/ https://www.reuters.com/legal/apple-wins-us-appeal-over-pate...

rokob 3y 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 3y 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 3y 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.
- ghaff 3y 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 3y ago
  Working like hell to meet an arbitrary deadline at all costs is a nightmare
baxtr 3y ago
How come it’s a nightmare at these places?
- johnobrien1010 3y 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.

Heloseaa 3y ago

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

ghaff 3y 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 3y 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 3y ago
It probably is actually good advice for a sole developer.

liampulles 3y 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-development.html https://tom.preston-werner.com/2010/08/23/readme-driven-deve...

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

Trasmatta 3y 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 3y 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.
deleted 3y ago
[deleted]

richrichie 3y ago

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

ergonaught 3y 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 3y 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.

deleted 3y ago
[deleted]

concordDance 3y 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 3y ago

This is a beautiful conceptualisation of the modern-day incentives

buro9 3y 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 3y 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).
- ghaff 3y 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 3y 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 3y 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 3y ago
This author, discussed previously: https://news.ycombinator.com/from?site=spakhm.com 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 3y 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 3y 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 3y ago

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

nickelcitymario 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago

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

jimnotgym 3y ago

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

from-nibly 3y 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.