4 ms·

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 strat

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 6y ago
What approach do they use?
- taylodl 6y 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.

mlac 6y ago

What approach do they use?

taylodl 6y 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.