[HN Gopher] Headline Driven Development
___________________________________________________________________
Headline Driven Development
Author : MrBuddyCasino
Score : 192 points
Date : 2024-04-01 08:40 UTC (14 hours ago)
(HTM) web link (www.spakhm.com)
(TXT) w3m dump (www.spakhm.com)
| anze3db wrote:
| This joke makes some good points.
| tgv wrote:
| Remarks like "work like hell" and ignoring everybody around you
| make it stand out for the April 1st joke it is, though.
| timwaagh wrote:
| Is that you boss?
| west0n wrote:
| The Reason Behind "Why Amazon forces its developers to write
| press releases"
|
| https://www.businessinsider.com/heres-the-surprising-way-ama...
| Muromec wrote:
| Ah, the date.
| amadeuspagel wrote:
| This is the last essay by the same author. Same tone. I think
| he's serious about this: https://www.spakhm.com/bullshit-ratio
| datascienced wrote:
| 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 wrote:
| 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 wrote:
| Also README driven development seems similar, with a different
| target audience.
| stanac wrote:
| That's what I do when writing libraries, now I have a name
| for it.
| oytis wrote:
| I've seen this idea in Tony Fadell's Build, didn't know it was
| Amazon thing.
| cjk2 wrote:
| 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 wrote:
| 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 wrote:
| Let us not forget the most important driver:
|
| NDDCDD - Noun driven development categorisation driven
| development
| majikandy wrote:
| 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 wrote:
| Simulacrum driven development
| yellow_lead wrote:
| 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 wrote:
| Isnt sprint goals just "do all the tickets"?
| Veuxdo wrote:
| Reverse it. The goals should point to what tickets to do.
| MrBuddyCasino wrote:
| Sprint goals are usually post-hoc: everybody tries to come up
| with an umbrella term after the tickets have been refined &
| selected.
| paradite wrote:
| This is formalized as having a press release at the start of PRD
| in product management.
| Shrezzing wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Working like hell to meet an arbitrary deadline at all costs
| is a nightmare
| baxtr wrote:
| How come it's a nightmare at these places?
| johnobrien1010 wrote:
| 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.
| ergonaught wrote:
| If you cannot simply articulate the actual need met by
| whatever you've shipped, you have failed to understand that
| need and probably even what you shipped.
| aerhardt wrote:
| The face of the author, if this isn't a joke and commenters
| in the thread are categorically affirming it is.
|
| 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.
| baxtr wrote:
| How can this be a joke if there are companies that actually
| work like this?
| lelanthran wrote:
| > 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.
|
| 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".
| johnobrien1010 wrote:
| Responses inline.
|
| > 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.]
| lelanthran wrote:
| > [JO:I agree that they are all goals. My assumption
| though is that just reaching those goals is not
| sufficient for success.
|
| 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].
| johnobrien1010 wrote:
| > [JO:I agree that they are all goals. My assumption
| though is that just reaching those goals is not
| sufficient for success.]
|
| 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!]
| onionisafruit wrote:
| 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 wrote:
| Can't this be qualified more simply as the Parkinson's law in
| action ?
| ghaff wrote:
| 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 wrote:
| 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 wrote:
| It probably is actually good advice for a sole developer.
| liampulles wrote:
| 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 wrote:
| I've been developing my side projects like this for a while. I
| didn't know it had a name!
| Trasmatta wrote:
| > 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 wrote:
| 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 wrote:
| > Most of the work in college happens at midnight before the
| project is due. The industry isn't that different.
|
| LOL, no.
| ergonaught wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| This is a beautiful conceptualisation of the modern-day
| incentives
| buro9 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| corytheboyd wrote:
| 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 wrote:
| 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 wrote:
| Firing our agile consultant has really freed up budget to hire a
| "headline consultant"!
| nickelcitymario wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Too wrote:
| Isn't this how Jira works already? Spend lots of effort on
| writing a ticket description that nobody reads beyond the
| headline anyway.
| ilaksh wrote:
| 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 wrote:
| This is great. It's so simple it hurts.
| jimnotgym wrote:
| sed -i 's/milestone/headline/g' spakhm.com
___________________________________________________________________
(page generated 2024-04-01 23:02 UTC)