6 ms·

Risk-First Software Development

• indymike 6y ago
  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)
  • zupa-hu 6y ago
    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. All right the sitemap says 127 pages.
    • eyelidlessness 6y ago
      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.
      • ineedasername 6y ago
        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.
  • macjohnmcc 6y ago
    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.
    • indymike 6y ago
      I think some embedded medical device software developers might have a dog in the hunt.
      • macjohnmcc 6y ago
        Yeah if there are lives at stake that’s the important stuff.
• josephg 6y ago
  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.
  • badconvincer 6y ago
    Is this a joke or have people really forgotten about waterfall already?
  • nicbou 6y ago
    It's missing step 0: properly defining the problem. This is a process we tend to skip because we already have a solution in mind.
    • josephg 6y ago
      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.
      • nicbou 6y ago
        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.
• waheoo 6y ago
  Is anyone else confused about how you're supposed to read this thing? Would appreciate any hints.
  • guavaNinja 6y ago
    Start from the summary then follow the intro https://riskfirst.org/overview/Quick-Summary https://riskfirst.org/overview/Quick-Summary They could have layed-out the articles better than this.
    • Noumenon72 6y ago
      That should definitely be the first page you see. Instead, I never even found it. Thanks.
  • wrnr 6y ago
    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.
• oa335 6y ago
  I clicked around the site and skimmed a few articles but I can’t figure out what exactly “Risk-first” development entails.
  • sova 6y ago
    > 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?"
• doublerebel 6y ago
  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.
• saurik 6y ago
  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).
• aazaa 6y ago
  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. You might call this Problem-First Writing.
  • austincheney 6y ago
    Or BLUF. https://en.m.wikipedia.org/wiki/BLUF_(communication) https://en.m.wikipedia.org/wiki/BLUF_(communication)
    • smichel17 6y ago
      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.
      • chrisweekly 6y ago
        I do the same thing, and like you also appreciate learning of a term for this approach.
    • tunesmith 6y ago
      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.
• deleted 6y ago
  [deleted]
• deleted 6y ago
  [deleted]
• agloeregrets 6y ago
  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.
• jandrewrogers 6y ago
  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”.
• r4nd0mdink 6y ago
  Define spec. Implement spec. Refactor spec and implementation. The details after that are problem specific. These frameworks drive me nuts. Software is not a car. I can do the same stats on a reasonable data set with a bit of C or UNIX tools. The only thing that’s different at scale is businesses trying to do it for us, for their financial gain. Forcing humans to move and bend like they’re robots in order to minimize risk to private finance fiefdoms is some thought policing nonsense.
• pgt 6y ago
  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. But this is not what the article is about, which is described under Quick Summary: https://riskfirst.org/overview/Quick-Summary https://riskfirst.org/overview/Quick-Summary
• 4778468d 6y ago
  I’ve always built the riskiest parts of a project first. It’s self evidently the way to build software isn’t it?
• ChrisMarshallNY 6y ago
  I’ve learned a fairly practical approach to this. 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.
• fefe23 6y ago
  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.
• ealexhudson 6y ago
  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.