4 ms·

To me, 80/20 is somewhat recursive. For 20% of the effort, you get 80% of the value. Then, within the remaining 20% of value, you can find another 20% of the ef

To me, 80/20 is somewhat recursive. For 20% of the effort, you get 80% of the value. Then, within the remaining 20% of value, you can find another 20% of the effort that gives 80% of the remaining value. Repeat infinitely. As such 80/20 is a useful tool in estimating how much effort it will take to get to a certain level of perfection. If you are working on a heart pacemaker, 99% isn't good enough, but you do have to define what is. How many nines of reliability does a pacemaker need? Once you have the answer to that, you'll be able to figure out how many iterations of the 80/20 rule you're going to have to go through to get the reliability you want. Obviously in real life it's not as clean as always being 80/20, but generally the idea that the last 9 of reliability takes as much effort as all the nines that came before it holds pretty well.

100011_100001 5y ago
What's interesting is that pacemakers are not 100% reliable. This is why there are things like electronic scales that measure % BF that tell you to not use them if you have a pacemaker.
taylodl 5y ago
I've been developing software for over 35 years and this is exactly the approach I and most of my teams (well, the successful ones anyway) have taken. The strategy is to show viability and let business drivers determine how and when to best tackle that 20%. The pursuit of perfection is the pursuit of failure. P.S. - I've also worked in shops where bugs in software can result in serious harm or loss of life. Guess what? They don't use this approach.
- mlac 5y ago
  What approach do they use?
  - taylodl 5y ago
    It's similar to the defense in depth strategy used in the cyber space. First, you need to start with a real-time OS (RTOS). We used Microware OS-9. You need to ensure you have processes or tasks guaranteed to run at set intervals. Then you need to use a language that doesn't have garbage collection. Again, you need to know that the code you write will be run in the time you measured - you can't have garbage collection interfering with those timings. We used Objective-C (this was the early 90's - and remember, Objective-C was not a language invented by Apple). They desired the object-oriented nature of Objective-C with the runtime predictability of C. They felt C++ was too difficult to analyze. Which is a good seque into the code. Yes, we used static analysis tools and performance analysis tools. We needed to know exactly how long each section of code took to execute on our target processor. We also did a lot of unit testing and had extensive integration testing. We had a dedicated build manager who ran the build daily, ran the unit tests, ran the integration tests, and ran the performance tests. They sent out a daily report. This was a full decade before anyone had created what we now refer to as CI/CD tools. All told I would say there was a 4:1 testing-to-coding ratio. Our customers never experienced any issues with our system not working properly - and these were industrial users in complex manufacturing environments. Feature management is a serial process. You add one feature at a time and thoroughly vet it before adding the next feature. The marketing department prioritized features - usually based off what customers needed for their upcoming projects. We released on a set schedule so customers could plan their updates.

100011_100001 5y ago

What's interesting is that pacemakers are not 100% reliable. This is why there are things like electronic scales that measure % BF that tell you to not use them if you have a pacemaker.

taylodl 5y ago

I've been developing software for over 35 years and this is exactly the approach I and most of my teams (well, the successful ones anyway) have taken. The strategy is to show viability and let business drivers determine how and when to best tackle that 20%. The pursuit of perfection is the pursuit of failure. P.S. - I've also worked in shops where bugs in software can result in serious harm or loss of life. Guess what? They don't use this approach.

mlac 5y ago
What approach do they use?
- taylodl 5y ago
  It's similar to the defense in depth strategy used in the cyber space. First, you need to start with a real-time OS (RTOS). We used Microware OS-9. You need to ensure you have processes or tasks guaranteed to run at set intervals. Then you need to use a language that doesn't have garbage collection. Again, you need to know that the code you write will be run in the time you measured - you can't have garbage collection interfering with those timings. We used Objective-C (this was the early 90's - and remember, Objective-C was not a language invented by Apple). They desired the object-oriented nature of Objective-C with the runtime predictability of C. They felt C++ was too difficult to analyze. Which is a good seque into the code. Yes, we used static analysis tools and performance analysis tools. We needed to know exactly how long each section of code took to execute on our target processor. We also did a lot of unit testing and had extensive integration testing. We had a dedicated build manager who ran the build daily, ran the unit tests, ran the integration tests, and ran the performance tests. They sent out a daily report. This was a full decade before anyone had created what we now refer to as CI/CD tools. All told I would say there was a 4:1 testing-to-coding ratio. Our customers never experienced any issues with our system not working properly - and these were industrial users in complex manufacturing environments. Feature management is a serial process. You add one feature at a time and thoroughly vet it before adding the next feature. The marketing department prioritized features - usually based off what customers needed for their upcoming projects. We released on a set schedule so customers could plan their updates.