Why long-term plans don't work and how to fix them

Vision informs mission. Mission provides context for strategy. Strategy constrains roadmaps. Roadmaps provide measuring guides for plans. Plans line up the day to day work.

Vision is why you do what you do. It is your North Star, the reason your company or your team exists. It should rarely, if ever, vary. Yet it should be revisited every 5 years, at a minimum.

Mission is what you intend to achieve. It outlines what is in your scope, and out of your scope. Revisit it at least every 2 years.

Strategy is how you will achieve your mission, and how what you do will move you toward your vision. It brings market data and analysis to the party. Revisit it at least once a year.

Roadmaps show when milestones of the strategy should be achieved. They are guides for expectations. Stakeholders typically begin consuming information at this level. Roadmaps are not plans, they are measuring devices for strategic progress. They must be adjusted quarterly, and will often change.

Plans (sprint plans, projects, task lists) show who is assigned to deliver small decomposed pieces of the overall work. They line up to roadmaps and strategy, but they are what is real. Adjust them at least each sprint.

There are other structures, feedback loops, inflection points, and ways to measure and adjust these components, but they are all commonly spoken of together as a "long term plan" without laying hyper-technical baggage on the word plan.

I thought this was product management 101.

I very much disagree with the article.

Long term plans do not work very well for sure. But they're not _meant_ to. Long term planning is meant to give people an idea of what's coming after.

This is important because what's coming after may change the implementation of what you're doing now. Some people in the team may say: "hey if we did 3 before 1, then we'd have 2 for free".

Estimating the time it will take to do things is also important cause you may think that you know what's coming after, but if you don't know how much time it may take (apply a 0.5-2 multiplier range), you may actually never have time to do it.

Keep making plans. Keep selling them to stakeholders, and keep telling them that it's just a rough plan and that details will be very different.

In any case, it'll cost you more pain to fight your CEO and tell them that you don't want to make a 1-year plan, than to actually making a 1-year plan...

Long term plans do not work out, because we have the wrong format for them.

A long term plan should be not a linear chain of events. But a scenario-tree. You are always at root - the now. Now you gain a new a capabilitz or the world changes around you, and the tree adapts. Its branches thicken were they become more likely. Unlikely scenario branches wither away. The whole structure is recursive, one capability reached makes other capabilities more reachable, but might introduce risks, that shrink the whole tree down.

This scenario tree is not focused on a single product, as a product is just one of many expression of a capability. But when the capability is reached, the whole thing has changed, including your view on risks and rewards while moving on. So pivoting might be in order. Meanwhile others move to similar trees, and change the world around you for the better and the worse.

To compress this structure down into a "historylike" sequence of events, is the main fallacy. The past may be a linear graph, but none the less a ever changing root-recursive-tree was traversed by those moving within it.

The reason we have deadlines and long term plans is financing. Nobody is going to give a development team a blank cheque to produce something they can't describe against no timeline. Furthermore there are often external constraints that impose deadlines and specific long term objectives. A hardware product launch for example. Even within companies, architectural or infrastructural constraints, or business commitments to partners, can add up to essentially the same situation as the agency exception.

All the problems the article describes are real, and I found it thought provoking and useful, don't get me wrong.

I disagree.

I think there is no single reason for why long term plans don't work. It is more like you need to do this dozen things right for the plan to work. The longer the plan the more things you need to be doing right to be able to see through the plan.

Accomplishing short term plans can be done relatively easily. There is less chance something unexpected will happen that will throw your plan into disarray. You have a chance to "just focus and get it done". You can take on debt in order to accomplish the task.

The longer the plan, the better you have to be at dealing with various things that require you to have much wider view of whatever you are trying to accomplish.

For example, if your plan is to loose 3kg in one month, you can just do it pretty much on your own with little interference/inconvenience to your wife and kids.

Try loosing 30kg over course of a year and you start having many more problems that you might not appreciate before you took on the project. Maybe your family is unhappy with the change of the diet and your schedule? Maybe your wife is unhappy with your lower libido/irritability? If you want to keep your gains you need to learn to make your diet stick and change your eating habits, which is super hard.

In a company setting you might find that long term project might need you to rethink many more things like how do you keep people dedicated/motivated when it is hard to see the distant goal? How do you keep yourself motivated? How to deal with people leaving the project? How to deal with more urgent/short term project preempting the long term goal?

While the problems presented are real, the solution proposed is laughable. None of these are new problems. It’s amazing how often we think we’ve discovered something new when it’s really an age-old problem that has been debated forever.

I like to sum it up as the tension between two contradictory yet true axioms:

(1) Failure to plan is planning to fail.

(2) No plan survives contact with the enemy.

You can’t just abandon long term thinking because it’s hard. Grow up. You’re an adult. Life is hard. You still need to have a destination in mind. The path to getting there probably won’t look like the one you planned, but your odds of success are much better when you both have a plan and are ready to adapt and evolve that plan as you go.

My experience is that the only thing that actually works is making the plan simpler. As in: implement the simplest version of whatever you're building at the same time being mindful that you'll have to eventually include all the features.

With such a solution:

-You can start dogfooding early on.

-There's less to go wrong.

-There's less sunk cost in those of the features that don't make it to the final product.

Integrate one of all those payment processors that were required, one external API and move on. Also don't do fancy, handcrafted components on the frontend. Or component libraries for that matter. Have separate tickets for validation.

Once you're finished with that you'll find that in the meantime the Nth payment processor went bankrupt, Nth external API was deprecated and UX finally managed to convince the stakeholders that a color picker the shape of a peacock following the mouse with its gaze is not the best solution in terms of user experience.

This is extremely long, but the fact of the matter is that these long term plans don't matter anywhere. They're a way for a relatively work-free layer of managers to feel like they have a hand in real work. After the plans are made, they can be burned: Their use was purely emotional, solely for people that won't be executing the plans.

Long term plans do work.

The Marshall Plan worked.

The James Webb Space Telescope took two and a half decades of effort, but the plan worked.

I could list a thousand plans that worked.

Now, why do we, as software developers, not think plans work? Because they're less well suited to our domain and the reason for that is that our domain is incredibly complicated, changes frequently, AND it's incredibly maneuverable.

What this means is that its more efficient to rely on this inherent maneuverability and build fast feedback loops to code our way towards a vague goal than it is to start planning for something 20 years away.

Is someone really going to game out whether webhooks or HTTP long polling are going to fit 2042's software landscape better? No. It doesn't matter. There will be transports for data. There will be instruction sets. The abstractions will change and morph over time, but it's not fruitful to ponder the explosion of possibilities. It's enough to pick a direction and step on the gas and figure out the rest as you go.

I agree with this but would state it differently.

This most often comes up in rewrites (which are usually a mistake) and the problem is that time doesn't stop once you start you rewrite (or, more generally, your long term plan). Features get added to the original. Bug fixes are made. Software entropy happens. These need to somehow be folded into your new thing. Or worse, you halt new development on the old while you write the new.

I've seen pointless rewrites with a 6 month estimate take 3.5 years to deliver, all the while the once-leading old version languished.

More generally a lot of this comes down to risk management. Your long term plan needs:

1. Shorter term milestones. Due to changing circumstances you may end up terminating your long term plan early. You should aim to have something to show for it if that happens. Ironically, having something to show for it makes this outcome less likely;

2. Reversibility: your migration (data, software, etc) needs to be reversible; and

3. Incrementality: you need to be able to gradually roll out your long term plan. It can't be all or nothing.

This is a common pattern in data migrations:

1. Double-write to the old and new systems. Start doing this with a small percentage of users (<=1%). Identify problems, fix them, rinse and repeat. Do nothing with the new data;

2. Increase the rollout to 100% gradually;

3. Have the system be able to read from the old or new system and work fine;

4. Roll out a small number of users to read from the new system. If this goes badly, you just read from the old;

5. Identify and eliminate all the old call sites reading from the old;

6. Once old data traffic gets to zero you can switch it off.

I've seen too many systems where the project plan is basically to shut down development for 18 months while you write the new (often leaving non-critical bugs in place), do a 3 day data migration where the system is down and hope everything works.

There is a balance with all things, but I’ve started to default heavily to execution.

The best way to figure out feasibility and timing is to just start doing whatever. Presumably, we are talking about software and computers so mistakes are cheaper.

An estimate that comes out of 15 minutes of trying to do that actual thing is infinitely more informed than one that a committee deliberates for months.

Feels like obvious link: The tyranny of the plan [0]. As a bonus, you will learn interesting facts about construction of Empire State Building.

[0] https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...

I agree with both the article and the commenters who are vehemently disagreeing. We need to understand how planning is used by different people for different goals:

1. Vision: setting long-term goals and speculating on the path that will best meet those goals.

2. Incentives and accountability: trying to make sure a team delivers X in Y time.

Setting a long-term vision is of course extremely valuable - find me a great founder or leader who doesn't have a long-term vision! It's the trying to force X to happen in Y time that increasingly breaks down over longer timelines.

Interesting article about long term planing. It does bring forward some interesting thoughts about how one should execute on a plan, but mostly I find it interesting in how this article misses the point of a plan.

I’d like to propose a slightly contrarian, if not, more nuanced view of what is the purpose of a plan.

If one considers a plan as a map that must be followed in minute details, to travel the proverbial territory then, of course, you’re much better with small, unplanned iteration that allow you to learn from each story you deliver.

The image that the author proposes is a very powerful one: yes it is much better to play the lottery by buying one digit at a time, because overall, you’ll cut your losses short in most cases.

However, this only focuses the value of the plan in it’s execution phase, absent from the planner, and the feedback he will get from the divergences from the plan, and the updates he will be able to bring to the mental model / explanation linked to the plan.

Let me be clear: *plans are meant to fail*. Why? The value of the plan is in *HOW* the execution diverges from it, and in so help us to update how we think and reason about the world.

Each plan, has as origin an explanation, theory, of how the world/market/customer works. Changing your explanation of how the world works is the goal of learning. To learn, you must make predictions. That is what the plan is, a simple prediction. Of course we should not expect those to line up with reality 100% of the time. It is quite the opposite: *expect your plan to fail* but most importantly *improve your understanding of the world / your market / your customer based on what you did not predict.*

I'm surprised how much time is spent thinking about planning and execution, and so little is really discussed about defining goals well. Because I've found that goals are often really vague, and frequently, they shift. And, shocker, if you change your goals you need to change your plans. Also, if you're not able to see progress against your goals, you probably need to change your plans.

A basic framework like "SMART" can help. But it does require some careful management; people can get really, really conservative if you're not careful, i.e., "undercommit and overdeliver" becomes a mantra. Some engineers and their direct management will throw up a lot of roadblocks to avoid looking bad.

This tension between trying to deliver consistently vs trying to take on bigger problems absolutely wrecks plans. If you want to deliver consistently, just focus on small problems. But not all problems are small, and some are even hard to break down because there's a lot you simply won't know. Periodically redefining and re-evaluating your goals is probably "step 1" in this process, and from there, the plans should flow.

This article assumes a very narrow definition of "long-term plan", yet doesn't give that definition to the reader. Here are some clues towards that definition:

> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget

"The plan does not look at the usefulness of work done. The plan decides in advance on a time frame and budget for each feature."

> Consequently, to make up for these delays, teams are pressured to deliver the next feature in less time than they originally estimated.

"The plan must be rigid with respect to unforeseen bugs. Scope or time frame cannot be adjusted."

> Consequently, long-term plans either force you to stick to useless features or pressure the team to accelerate the following features to compensate for the delay created by listening to feedback.

"The plan does not allow adjustments based on feedback."

Must be nice to live in such an alternative universe.

In companies where I've worked, a few Fortune 500 ones included, there is this thing called "budgeting". More formally called AOP, Annual Operating Plan.

Your team, IT department, whichever...gets a budget. For the year. And you're going to tell the owners/accountants what they get for that. And it isn't just going to be "we'll add dark mode", it's going to be tied to bottom-line business metrics like revenue, cost of non-quality, compliance, etc.

Further, this budgeting exercise also reveals cross department dependencies, critical path issues, etc.

Of course, this still doesn't mean that the plan will fully work out, but this idea "let's just not do it or wing it" doesn't really work. At least not in the companies described above, but things are likely much different in well-funded startups.

You make a plan not because you expect to follow it but because making a plan forces you to consider both the situation and the resources you have available, then when the plan falls apart as they nearly always do you at least know what you have available to deal with it.

The reason time planning doesn't work for most teams is not neatly broken down into two points as in TFA. There are way more than two points. Consider confounding factors like computer/power outages, windows updates, bugs in upstream, developers' personal lives, etc etc etc. One hung over developer day, poorly timed, can add weeks to your project. To accurately predict a team development process you would need Chaos Theory level of mathematics (and foreknowledge of variables). Asking developers to guess time values for tickets and adding them up does not cut it.

OR you handle it the way casinos do, using the law of large numbers[1] to make extremely accurate predictions over many consistently-produced values. There's a good reason why every single formal study on estimation, and every single agile framework has come up with abstracted estimation units and the same velocity calculations. A mature estimation process, run for a month or two, will give you medium- and long-term estimates that are at least within 5% of reality - that's perfectly useful for long-range planning. So the first half of the article is simply showing off that the author has never learned about professional estimation processes. Fair enough, most developers haven't.

Others have already pointed out in this thread that the purpose of long range planning is to indicate what we expect comes next. TFA acknowledges this as a good use of long-range planning.

There is one good remark in there, however:

> Instead of rewarding teams for delivering useful, profitable features, companies which worship conformance to plan reward developers for features on time and within budget; it doesn’t matter how useless or broken those features are.

As an organizational principle this is exactly correct. By all means use long-range plans, and adapt them as the situation changes. But don't build a rewards scheme around them!

[1] https://en.wikipedia.org/wiki/Law_of_large_numbers

"Plans are useless but planning is indispensable" D. Eisenhower

There are a lot of opinions in this discussion but I'd like to steer things toward the concrete.

Could you people on HN share some numbers? If I get a lot of good responses I might present a summary later.

1. How long do you usually spend making your long-term plans?

2. How much time does one of these long-term plans cover?

3. How often do you make these long-term plans?

4. How often do you end up abandoning a long-term plan to do something more profitable as it comes up?

5. How often do you pass on doing something more profitable because you choose to stick to your long-term plan instead?

Software project productivity guru Tom Demarco, after a long career, had a kind of eye-opening mea culpa moment about project planning:

"I thought all late projects were the same in that they were really estimation failures, not performance failures. I still believe that all late projects are the same, but for an entirely different reason. All projects that finish late have this one thing in common: they started late." -- TD

I think the underlying reason long term plans don't work in most commercial software development is that accurately estimating software development effort or schedule is the same order of magnitude complexity (CS big O) as implementing that software. If people could efficiently generate accurate estimates (and therefore schedules and plans), they would. It turns out to be hard even in a static world, and impossible in an unpredictable dynamic one. The fundamental issue is that developing software is 'design all the way down', it rarely turns into 'mechanical assembly' - in general, each line of code written is designed. That was one of the insights of the agile movement - the implementation 'stage' required considerable 'design' (or re-design, as the case may be). The difference between the coders and the architects is simply the scope of the abstractions. A successful architecture can reduce the scope of abstractions necessary when implementing specific bits - but it can't eliminate them.

I learned how to play the long game, from the Japanese.

My company used to have ten-year major product cycles. They have since, shortened it, but it was still at least five years ahead.

They would have a "long range" plan, that looked many years ahead. It would be strategic, and very "fuzzy," with tea-leaf reading and crystal ball-gazing. They would deliberately eschew details.

It was like looking at a map, and saying "We should go West."

They would have a "middle range" plan, usually, about a year ahead. Sometimes, eighteen months.

It was like saying "We should follow one of these highways, West."

Then, they would have detailed "project plans," that would be (in my opinion), way too detailed and mapped out. These were usually handled in six-to-nine-month milestones.

It was like saying "We should follow this highway, and take this side road," etc.

I follow a similar pattern, in my own work, these days, except that I keep my project plan flexible, and pivot as necessary; sometimes, on fairly short notice.

> 1. Nothing will go wrong 2. Product developers know precisely what they must build 3. Product developers know exactly how long each task is going to take

If your plan is built with these assumptions you are not very experienced at long term planning.

The real reasons long term plans don't work well in real life is are:

1. People don't spend enough thought on strategy before putting the plan together [1]

2. The people assigned to make the long term plan often don't have buy in for the results

3. Most management teams have, at max, a 1-2 month attention span

The most important result of a long term plan is that it produces a collection of important, documented, well understood projects and their relevant priorities and approximate costs.

[1] See comments on "Why don't we have a strategy?" https://news.ycombinator.com/item?id=32094469

I agree with the sentiments but there are a number of things that make this hard, some already alluded to.

The idea that something we "need" but maybe not in the top 5 and it seems weird to deal with it with "bring it back to each meeting until either you don't want it anymore or it becomes top 5", why not instead put it into the roadmap?

Someone else has alluded to external investment driven by strategy and long-term plans. It is uncomfortable if there is no long-term plan even though we are told that investors invest in the people, not the product.

Some tasks are long-term and might involve communication with customers, deadlines to deprecate something, other work needed to support something. If all of this will take 1 year in elapsed time, you can't simply forget the later bits since the earlier bits are only being done to support the later bits.

I only skimmed the article yet it it is ridden with weird takes on management.

Let me give you an example. You go on touristic vacation. Most people would plan the core sights to be seen and places to be visited, probably center all that around pre-booked places to crash for the night. This article sort of advocates shortening the plans to half a day plans, because you might to go a tad bit different route.

Of course there are uncertainties and the longer the term, the more uncertainties. Knowing exactly how long a task takes is worthless if you do not know what and why you are building. Where does the itemized list with well-defined tasks for sprints come from? The longer term plan. Both are very relevant, but are tools used at different levels.

Without long term plan Facebook could have ended up a dating app or blogging platform.

I think the article could be improved by defining or giving an example of a long term plan.

At the start of each year we have a plan, but it's a rough plan. We know we have certain external constraints that need to be met, for example system A is moving from sending XML files via SFTP to a REST API in June. If we already know the scope, we'll have some rough dates for when we should be ready for testing and so on, if not we have some (much) earlier dates for studying documentation to determine scope and requirements.

We also have some internal goals we would like to meet, for example making a new module for doing X. They also got some rough dates attached.

This yearly plan is then used to ground our short-term planning.

However, I didn't get the feeling that it was this sort of long term plan the article had in mind.

Don't plan - have a goal. Just like in war, your plan will have to change as you go along.

Long term planning is perishable. The applicability and value of any detailed task within a plan is likely to be low in 2-6 months.

Or in plain english: ~70% of detailed JIRA tickets written more than 6 months ago will need to be updated significantly or get closed as 'wont do'.

The problem with "long term plans" in this context is them being linear. Basically, most "plans" in practice are just fictions to lower anxiety.

Real "Plans" are trees. What is being presented as "the plan" is just the most desired or likely path from root to leaf. The problem emerges when people stop considering the rest of the tree exists. The primary thing to focus on in planning is "decision points" and the branches they point off to.

Then deal with all your workers/coworkers/bosses getting frustrated with your "too complicated" decision tree based plan and ask you to throw away 99% of it because they would rather ignore undesired/nonideal futures.

I’ve been thinking a lot about this exact problem lately. If we accept the concept of “better / faster / cheaper”, but the velocity and cost of a team is fixed, then the only variable is “better”.

This means that we can either reduce the feature count or we can reduce the code quality. If we stick to the plan (which inevitably talks about features) then it’s quality that will suffer, but reducing quality has a significant cascading effect on the entire project.

So the only real option is to change the plan - change the deliverables timing. But if the value of the plan was predictability, this option suggests that long term planning isn’t particularly valuable anyway.

I'm sure long term plan is composed of short-term plans. You don't make the long term plan work throughout 1 week!

So, the issue is, don't separate long vs short, but:

- Have a long term plan

- Decompose into short term plans

- Fix short term plan instead of changing the long term plan.

- Enjoy the ride.

I just finished one of the books cited in this article: The Principles of Product Development Flow: Second Generation Lean Product Development. Strongly recommend it. Huge focus on the economics of product development.

Your ability to plan into the future is polynomial; the future's ability to do things you didn't expect is exponential. Reasonably low factors on each, at least generally (sometimes reality goes through periods of a much larger factor making planning hard even in the short term), but they're still in different classes. Combined with the fact planning is not itself free and a lot of the rest of the analysis after this becomes pretty obvious.

A plan is not supposed to be set in stone. If the assumptions change, or progress is not going according to plan, you re-evaluate the situation and change the plan accordingly. The plan might have been to go on vacation in Japan, but because of Covid lockdowns you changed the plan to instead go on vacation in your own country. It’s a different plan but it still achieves the objective: going on vacation.

I was expecting to see splitting the long term plans into multiple shorter wins. This ensures we celebrate wins and have a leading and lagging indicators. Constantly measure and iterate. If anything, pivot. Is that not how long term plans work.

In reality none of the long term plans have worked apart from long term habits and principles. Plans are there to fail.

"War will not go according to the plan but no war was won without a plan " :)

I find an uncanny correspondence between the recommendation given here, following as it does from an interpretation of the Agile manifesto, and Brian Will's procedural programming recommendation contra OOP in his classic 'Object-Oriented Programming is Bad'[1]

[0]https://www.youtube.com/watch?v=QM1iUe6IofM

Long term outlooks work provided you scale the resolution, contrast etc... proportionally. This is how I identify the forest from the trees.

"Assumptions are the mother of all f_ups." That is what I've always learned, and experienced. My entire dayjob consists of finding the assumptions people made, and exploiting them.

Yet, here we are. In Agile Land. And _everyone_ treats assumptions as some proven datapoint. We now call them 'estimates'. But if it looks like a duck....

>> responding to change over following a plan

That's how Agile has gone wrong in practice. Responding to change is a true need, however, lack of due diligence to understand the current requirements is not. However, that's the way I see this as being used -- Start working now, we'll figure later.

Let's be real, the main reason these plans don't work out is because management changes their mind every couple of weeks.

There are very few software shops with the management discipline to not change a plan for a full year, because the plan is working.

Yeah, don't make long term plans, just try random directions until something sticks. I'm sure Google would like to hire him.

Adjusting the long term plans constantly is an entirely different animal.

But then you don't have an end date.

Deadlines are useful. Yes it may need to be pushed back but saying it'll be ready when it's ready with no time frame is not, in most cases useful.

This is a great article.

I once gave a version of this to a manager and he replied by telling me that nothing gets done without a deadline.

He kinda made a point. Curious to see what people think about this?

To an extent I think it comes from looking at other companies out there that have achieved something and thinking that they planned everything about where they are now.

I think it's good to have a long-term plan and goals, as long as it's fluid and can be adjusted as new problems/solutions arise.

Still better than no plan at all, which is the default way of people going about their lives in the TikTok era.

I get the impression that the author criticizes bad planning, or estimation.

To me, a good plan is a map of dependencies in time.

A plan and a backlog are two very different things. A backlog is not a plan. But having a backlog is still a good idea. Especially if it is prioritized and you have a clear idea of what you need to do short term and why.

That prioritization does not come out of nowhere, there need to be some business goals and a strategy. Those are longer term things that change less often. Often that is summarized in some kind of roadmap. A roadmap is also not a plan but more of a tool that you use to align short term planning with long term goals. Ours is adjusted on a quarterly level and we tend to try to figure out the two or three most important things that we need to make some progress on. And we set some targets based on that.

But a list of items that you want without a clear idea of how you are going to do these things is not a plan. Simple reality: unless you do waterfall, you won't have such a plan. And if you do, it's likely a bad plan. Adjusting plans regularly and figuring out business goals is something that happens a lot in software engineering. A classic misunderstanding is that that is a problem that needs to be fixed. It's a feature, not a bug.

Building software is simply not like manufacturing, architecture or other engineering disciplines where you work off blueprints on predictable schedules. Until those blueprints are done, planning an engineering project is not doable either.

You are not going to start building say a nuclear power plant without a very detailed plan and some blueprints and lots of analysis having taken place already. Of course, creating such a plan typically takes years and represents a massive investment in itself. And of course a common complaint with nuclear plants is that the planning stage is expensive, runs too long, and seems hard to plan. Agile nuclear plant design seems to be not a thing but if you think about it, the process of coming up with detailed plans for a nuclear plant has some similarities to how software projects work. Lots of uncertainty, constantly changing rules, requirements, legislation, and other factors. Maybe they should be more agile?

Anyway, in software, the blueprints are the main thing that you build. That's why it's called software. It's an executable specification of some sort. Building that specification is the whole work. Having a blueprint for the blueprint is not really a thing (though of course many have attempted this). You might sketch out bits of it on a whiteboard and do some mvps, prototypes, and what not. But that's not the same as a detailed plan either.

What's interesting is that some engineering companies are actually applying agile practices. E.g. the way SpaceX rapidly iterates on their prototypes seems a lot like the chaos you see in software companies. It seems to work for them and is very different from the way some of their old competitors work. What has changed there is that a lot of the work has moved inside computers. They are iterating on software, cad designs, using simulations, etc. Modern engineering inherently involves a lot of software. And you need to plan accordingly.

tl;dr: Long-term plans = Waterfall.

OT, but anecdotical: Just a month ago ago, it seemed, my girlfriend was 'multitasking'. Confused i asked her why she does something, left it and leave for a minute or two (in and out). She said: "This seem to be my way to get around 'oh-i-forgot-this-or-that'-surprises" ^^ (-kitchen-talk).

Some moments later i remembered, i had made a comic about exactly that. Searched for, and 5 (um no! way more years ^^) years ago we both sat in the kitchen, when i was writing a note after she confronted me with: 'you seem to forget too much!', after i had forgotten something. So i was writing when she ask me: 'what do you wrote?', and i told her 'A to-do-list'.

So she sayed: 'Show me...' i handed it to her, written on the sheet of paper was: 'What you can do in under two-minutes, do instantaneously !' (-;

edited:typo