Risk-First Software Development

The Overview page doesn&#x27;t describe the problem to be solved. If it did that, I&#x27;d at least know whether I have that problem and could decided whether to continue reading.<p>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.<p>You might call this Problem-First Writing.

I&#x27;ve been saying this for years; but I never had language to describe it - so thankyou for this!<p>I sometimes think about programming as having two distinct acts of creation:<p>1. Designing the program conceptually. This might involve whiteboarding, architecture overviews, design review, sketches, etc<p>2. Actually writing a working program<p>Writing good code is expensive and time consuming, so you want to bring any eureka refactoring &#x2F; 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&#x27;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 clicked around the site and skimmed a few articles but I can’t figure out what exactly “Risk-first” development entails.

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&#x27;d love it. (yes, sometimes isolating is impossible, and sometimes something is risky that you think is a sure thing)

I’ve learned a fairly practical approach to this.<p>If an aspect of the project requires research and&#x2F;or significant engineering&#x2F;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.<p>This is very important, if the feature is a “central” feature of the project.<p>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.<p>I call this the “Front of the Box&#x2F;Back of the Box” approach.<p>When we are designing product packaging, the front of the box may have only two or three major “eye-catchers,” in big, obnoxious lettering.<p>The back of the box may have three or four more, in slightly smaller font.<p>The sides would have still more, in even smaller type.<p>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 <i>always</i> get “first cold press” treatment; even if they aren’t particularly challenging or difficult.<p>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.<p>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.<p>But this is not what the article is about, which is described under Quick Summary: <a href="https:&#x2F;&#x2F;riskfirst.org&#x2F;overview&#x2F;Quick-Summary" rel="nofollow">https:&#x2F;&#x2F;riskfirst.org&#x2F;overview&#x2F;Quick-Summary</a>

Is anyone else confused about how you&#x27;re supposed to read this thing?<p>Would appreciate any hints.

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.<p>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&#x27;t overriding technical judgement.<p>Whether it&#x27;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&#x27;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.<p>Basically it&#x27;s a lot of name dropping of concepts and keeps promising to get to something later which it then doesn&#x27;t (within my time frame).<p>I loathe web pages like this, where the whole design is guided by flashy optics but they then don&#x27;t deliver anything.<p>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.<p>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&#x27;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.<p>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.<p>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.<p>Third, it buys me time to gain understanding of the problem space.<p>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.<p>There are risks with doing it this way, but I think you shouldn&#x27;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.<p>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.<p>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 &quot;risk-first&quot; 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 &quot;first&quot;--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 <i>even possible</i>: and so like, I spend my time arguing with people about how &quot;sure we could build that UI out but we don&#x27;t even know if we understand whether that easy UI you want is feasible yet, so let&#x27;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&quot; or &quot;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&#x27;t ready for&quot;. The examples I was seeing here were thereby &quot;great&quot; in the sense that they were &quot;correct&quot;, 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 &quot;we spend $5 million building a fancy product without ever once realizing it doesn&#x27;t work so hard it couldn&#x27;t even be done, because we front-loaded low-hanging fruit instead of having the engineers mitigate long-term risk from day one&quot;. 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.<p>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 &quot;bending reality to fit the proposed worldview&quot; - the definition of &quot;upside risk&quot; being an obvious case in point. Even in risk-based management systems, those would be referred to as &quot;opportunities&quot;.<p>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.

I’ve always built the riskiest parts of a project first. It’s self evidently the way to build software isn’t it?

Define spec.<p>Implement spec.<p>Refactor spec and implementation.<p>The details after that are problem specific. These frameworks drive me nuts.<p>Software is not a car. I can do the same stats on a reasonable data set with a bit of C or UNIX tools.<p>The only thing that’s different at scale is businesses trying to do it for us, for their financial gain.<p>Forcing humans to move and bend like they’re robots in order to minimize risk to private finance fiefdoms is some thought policing nonsense.