The Overview page doesn't describe the problem to be solved. If it did that, I'd at least know whether I have that problem and could decided whether to continue reading.
This is an extremely common failing in technical writing. Without a clear problem statement, the reader has no clue whether the writing is worth the time. And without a clear answer to that question, most readers will do the rational thing and head for the exits.
Thank you for the term for that! I do it in most emails. First I write it the standard way, because that flows the most easily for me. Then I find the sentence with the request I'm making or key point I want to get across, move it to the top (or subject!), and edit as needed so the rest still makes sense.
I wonder if any science has been done on this - to me there seems a tradeoff. BLUF might work for executives that trust their reports. But it might be the exact opposite of what you need if you're trying to convince an audience of something counter-intuitive.
If you're going to be educated about a conclusion that is surprising or objectionable, would you rather be told the non-controversial premises first and then share in the reasoning process that leads to the conclusion? Or would you rather be told the conclusion first, and then unpack the argument from there? The latter seems like it could invite more opposition and waste more time.
Solution: stop trying to do the exact opposite of the thing that hurt, because big surprise, that’ll hurt too. I don’t understand why we have such a hard time figuring this out. Too much time sleeping through intro to logic, I suppose.
You start with an easy one to prove you’re not completely insane for considering this idea. You move to the hard ones to make sure you’re not going up a blind alley. By the time you’re done, they’ll all be easier (and if they aren’t, then pain is information. Use it.)
If you haven’t done the hardest one by the midpoint, odds are good someone is relying on wishful thinking. But doing the hardest one first is masochism.
Software is written by humans. Humans need confidence, and practice. Jumping into the deep end will just teach them not to try. People who can do the hardest one first? Aren’t looking for advice, and so you don’t need to write with them as the target audience.
Make sure you have the "critical path" in focus and have/create a plan to go along it. "Easy things are easy" and you can do them along the way as side projects. It's tempting to do bike shedding. Manage risks and uncertainties. Though all this requires you to be senior and well experienced and some companies just don't hire these kinds of people, because they are too expensive.
I've been saying this for years; but I never had language to describe it - so thankyou for this!
I sometimes think about programming as having two distinct acts of creation:
1. Designing the program conceptually. This might involve whiteboarding, architecture overviews, design review, sketches, etc
2. Actually writing a working program
Writing good code is expensive and time consuming, so you want to bring any eureka refactoring / design moments as early as possible in order to decrease how much useless code you write. And for that you need to spend time nurturing the design in your head. Make prototypes. Test the database you're thinking of using. Make a simple in-memory prototype of the difficult logic. Make wireframes. Mine all that for clear headedness - you want a low risk, obvious road to tread when you build.
I usually only really understand the problem while iterating on the design. So I'd lump "understanding the problem well enough that you can solve it" in step 1.
Before starting: I've got a sweet idea for a web app!
After step 1: I'm trying to solve ___ problem for ___ users. My MVP will look like these rough sketches and I'm going to use build it on top of ___ libraries / databases / frameworks.
After step 2: Here's the website if you want to give it a spin!
The easier the code is to write, the less time I'll spend in step 1. Which makes sense - up front design won't save much programming time if I can make a prototype faster than I can write a spec.
Separating the problem definition from the solution could make you realise that you took the wrong branch right from the start.
You might refine the solution you came up with to match the problem, but you might invest a lot of effort building the wrong thing while a simpler, more obvious solution is right under your nose. When you pick a solution branch too early, you might be tempted to stick to that branch, and only notice the parts of the problem that fit your solution.
In your example, you might build the wrong thing based on your assumption of what your users want. You might realise at some point down the road that software wasn't even the right solution in the first place.
> here, we are going to consider a second perspective: that building software is all about managing risk, and that these methodologies are acknowledgements of this fact, and they differ because they have different ideas about which are the most important risks to manage.
can't say I understand it clearly either, but maybe the biggest mysteries you have in whatever application you want to make are the things to attack first? Kinda like "save the easiest for last?"
Interesting take. Front-loading risk is a basic project management strategy, and one that is really difficult to get right with software. The framework presented is way too complicated, and touches a lot of engineering dogma that will make it hard to sell, especially to teams using any variation of agile. If this were a simpler way to teach my teams to take stuff that is high-risk, isolate it, and do the risky part first, I'd love it. (yes, sometimes isolating is impossible, and sometimes something is risky that you think is a sure thing)
I too came back here to say "Interesting take". I didn't get to read enough of it so I hope to get back and comment on it later. That said, it feels a bit too daunting that I don't see a menu tree only links leading to yet another page. I feel lost. I'd love to have a map of the territory to be able to size it up. Currently I have no idea if this is 50 pages or 500 pages.
It seems like they frontloaded the risk of poor navigation to get launched /s. In all seriousness I’m curious about the proposition but after diving several pages deep in their page hierarchy I don’t know what they’re trying to assert/promote even as a vague philosophy and I’m not sure whether it’s worth my time. But if it’s still compelling after you get further in I’m open to persuasion.
Yes, a few pages deep and I still don't know where the rubber meets the road on this besides some generalities about risk and starting projects with it's analysis. As a stand alone concept I suppose that's fine, but as a software development method I need something more than that without having to dig through an oddly structured set of pages.
I've worked on mission critical software over a long period of time and it can be a challenge to be performant and also not fail or bring down the rest of the apps on the computer at the same time. Nothing as mission critical as flight software mind you.
If an aspect of the project requires research and/or significant engineering/development resources, most engineers will generally “front-load” these tasks, to “get them out of the way,” and maybe allow for further refinement, as the rest of the project progresses.
This is very important, if the feature is a “central” feature of the project.
However, if it is a feature that is not “critical path,” or something that could be added after an “MVP” stage, then work on it could suck the oxygen from the important (to the end-user) features.
I call this the “Front of the Box/Back of the Box” approach.
When we are designing product packaging, the front of the box may have only two or three major “eye-catchers,” in big, obnoxious lettering.
The back of the box may have three or four more, in slightly smaller font.
The sides would have still more, in even smaller type.
The “Front of the Box” features are always the most important ones to the end-user (or, at least, that’s what we believe). Those features should always get “first cold press” treatment; even if they aren’t particularly challenging or difficult.
That way, even if the technical “whizzy-bang” stuff goes pear-shaped, or takes longer than planned, a viable MVP is still available, to generate funding and support for continuing development.
It’s amazing how often this fundamental approach is ignored.
The title excited me because I have been advocating for tackling the riskiest part of any software project first because it reveals the most unknowns, thereby increasing the chance of success.
I like the moto, "do the hardest thing first", that way if it turns out something is impossible you know this as soon as possible.
One caveat is that it only works for known-unknowns.
This looks like a deep dive into the software development portion of the Riskiest Assumption Test. The RAT has gained popularity in recent years over the Lean MVP.
The RAT is really important in areas like Healthcare that require a lot of monetary investment to build an MVP. In my experience, the hardest part about the RAT from the technical side is convincing people before building that their MVP assumptions or technical understanding may be wrong. Technical RAT only works if estimates are trusted and management isn't overriding technical judgement.
Whether it's RAT or MVP, the most important priorities are still talking to users and working from solid data, to avoid leaning on assumptions.
This is pretty much Basecamp’s Shape Up but without any of the hard logic into the “How” right?
The entire goal of Shape Up is to remove and mitigate risk by frontloading it.
Like for everybody else here apparently, this page was useless to me. It didn't make clear what it is about, and after I wasted 20 minutes reading through it, I was no closer to the message than before.
Basically it's a lot of name dropping of concepts and keeps promising to get to something later which it then doesn't (within my time frame).
I loathe web pages like this, where the whole design is guided by flashy optics but they then don't deliver anything.
That said, people here appear to fundamentally agree that the riskiest part should be done first. So I would like to present the opposite view so we can start a discussion.
You will probably not be able to do the riskiest part first because you are missing infrastructure. So, if you strictly adhere to the dogma of doing the risky stuff first, you may make rash decisions about the structure of the final product, when you really don't know anything about it yet. You might pull in frameworks and tooling which later turn out to be a bad choice, creating additional stress to replace later.
Personally, I have been grappling with this for decades. Watching myself I usually tend to do easy infrastructure first. This has two major reasons. First it gives me time to think about how to actually approach the risky parts.
Second, if I then fail in the risky part, the work was not for nothing but I at least got the reusable infrastructure code out of it.
Third, it buys me time to gain understanding of the problem space.
Fourth, and this is particularly important for open source projects, it gives me a steady stream of successes after each puzzle piece gets finished. Without this stream of successes motivation fizzles and projects die.
There are risks with doing it this way, but I think you shouldn't unfairly just discard the whole idea. After all people are doing it like this all over the world. That probably means there is some kind of evolutionary background to it and it was actually better than the other approach.
I think a good rule of thumb is that you limit the risk about WHAT you are doing, not HOW you are doing it. By the time you tell your engineers what you are doing, it should be basically risk free.
To me it appears obvious that failure is too often blamed on engineers when it was really management failure.
I was very excited by this--to send it to the people I work with to explain to them a lot of my mental model--but was sad that the examples all seemed to be steeped in the world of an already well-established product with a large team. When thinking of "risk-first" the prototypes that come to my mind--due to how I am usually working on the small team that is trailblazing new territory, as well as simply thinking about what comes "first"--is how to ensure that the initial work being done is most directly derisking the entire concept of later execution plans, as we might have no clue of what we are trying to do is even possible: and so like, I spend my time arguing with people about how "sure we could build that UI out but we don't even know if we understand whether that easy UI you want is feasible yet, so let's try to build what we considered to be our killer feature first and then build the UI around it once we know what settings it simply has to have... in the mean time we can use a low-level command line tool" or "in three months I am going to come to you needing to be able to buy something, but I have no clue what that will be yet: I realize you are used to being given concrete goals, but I need you to start setting up payment channels and finding partners who are on board to be flexible with the changes that will be coming in two months without then getting ahead of yourself and starting to commit to things we aren't ready for". The examples I was seeing here were thereby "great" in the sense that they were "correct", but I could see showing this to someone and them getting the misimpression that the risks described and assumed--relating to integration with existing code and misunderstandings surrounding existing features leading to duplication and waste of work on a large team--will cause everyone I want to show this to to think those are key risks even for an early project... where in fact the biggest risk might be "we spend $5 million building a fancy product without ever once realizing it doesn't work so hard it couldn't even be done, because we front-loaded low-hanging fruit instead of having the engineers mitigate long-term risk from day one". If would be really interesting to have another version of this written from the perspective of a different place in a product lifecycle, starting at the very first things one does on a new project (which might include analyzing doing the risks of business deals at all ;P).
This only focuses on categories of risk that apply to low-risk software. As in, the risks are ordinary and largely a function of process and execution.
Ironically, it ignores the riskiest category of software development, classes of software that have never been built before or require necessarily bleeding edge software engineering. This is a very different kind of risk than “bad at software development”.
Some of this definitely comes across as "bending reality to fit the proposed worldview" - the definition of "upside risk" being an obvious case in point. Even in risk-based management systems, those would be referred to as "opportunities".
Viewing all activity through a single lens feels extremely reductive, and the language of risk is already understood in different contexts within business to mean something a bit different.
This is an extremely common failing in technical writing. Without a clear problem statement, the reader has no clue whether the writing is worth the time. And without a clear answer to that question, most readers will do the rational thing and head for the exits.
You might call this Problem-First Writing.