4 ms·

Thank you so much for your detailed reply! That's a lot to think about :) Thanks for the hints about defects. I like "unacceptable code", but it's probably sti

by struppi 11y ago

Thank you so much for your detailed reply! That's a lot to think about :) Thanks for the hints about defects. I like "unacceptable code", but it's probably still a definition not everyone can live with :) "It's Not Much Slower Anyway The Microsoft study on TDD" "You're conflating quality and testing here. They're not the same." You are right. My arguments here are only for TDD, and I actually did not want to write a TDD article :) I'll think about how to improve that section. Also, CleanRoom is really interesting, but I don't know very much about it and never experienced it. "At some point, your users will recognize that it takes longer and longer..." "Should be one of the top points." I was thinking about the order of the points a lot, and no particular order seemed really right. It now comes at a point where I think I have established all the preconditions: Speed means lead time, cost depends on speed, high external quality means faster, high internal quality means faster. But you're right, the main points I want to bring across come very late in the article. As for the illustrations: Maybe I'll write another article about how users care about internal quality - Because I've worked in so many legacy code projects that I think I have a good view on that :) I like your points about the iOS stuff and the short-term jobs. I'll think about them some more. I'm still not sure if I believe the "unlimited downside" idea 100% (because only very few things are truly unlimited), but it's an interesting concept.

nickpsecurity 11y ago
" Thank you so much for your detailed reply! That's a lot to think about :)" You've very welcome. :) "Thanks for the hints about defects. I like "unacceptable code", but it's probably still a definition not everyone can live with :)" I kind of came up with it off the top of my head. Point is that the code will be rejected on relatively arbitrary criteria. It might be known defects, coding style, what libraries were used... anything. Hard to find a word or phrase covering all that which people will agree with. "Also, CleanRoom is really interesting, but I don't know very much about it and never experienced it." This presentation... http://groups.engin.umd.umich.edu/CIS/course.des/cis376/ppt/lec21.ppt http://groups.engin.umd.umich.edu/CIS/course.des/cis376/ppt/... ...summarizes it for you in about 5 min of reading. The first attempts to make software in a scientific way, engineered software I call it, were done by Margaret Hamilton (founder of our field) at NASA plus academics like Dijkstra and Hoare. They all produced nearly defect-free systems in a systematic, often mathematical way. Harlan Mills took the lessons to industry when developing Cleanroom: a combo of lightweight formal methods, design constraints, spec/code verification, incremental development, and usage-driven testing. He wanted SW products to be as low-defect as HW clean rooms. Result was code at extremely low defect rate that was consistent enough for statistical certification. While popular, Cleanroom teams actually warrantied their software. Altran/Praxis is another company I know that (a) truly engineers software and (b) warranties it at specific defect rates. Defect rates are usually better than the Linux kernel and close to the Space Shuttle's control code. Here's a case study of their Correct by Construction process applied to high-assurance, certificate authority: http://www.anthonyhall.org/c_by_c_secure_system.pdf http://www.anthonyhall.org/c_by_c_secure_system.pdf So, there's you two methods that already maxed out quality (and/or security) on real-world projects. Altran charges an acceptable premium for quality but Cleanroom often cost nothing extra or saved money for same reasons as you article says. Appears the modern programmers still have lessons to learn in software quality from the 1980's. Like I tell people, the old wisdom is often pretty solid even after you fix outdated parts. Our field is just terrible at passing it down. I try to fix that with posts like this so the smart, young people get a boost toward whatever great things they create. Also reduce endless rediscovering of fire and reinventing the wheel. :) "I was thinking about the order of the points a lot, and no particular order seemed really right. It now comes at a point where I think I have established all the preconditions: Speed means lead time, cost depends on speed, high external quality means faster, high internal quality means faster. " I'm going to let you keep working on that formula. You've got the right ingredients. Far as order, there might not be any. Many things in engineering or business are holistic where the parts all feed into each other. The goal is an emergent property of that. So, rather than an order, you'd visualize it like a bubble chart or something that with connections between the components and labels for the effect they have. Just something that's clear that they're all connected, all feed into each other, and ignoring one breaks the process for achieving the goal. Just my dos centimos. "Maybe I'll write another article about how users care about internal quality - Because I've worked in so many legacy code projects that I think I have a good view on that :)" You should. Matter of fact, you should do a lot more work on figuring out how to measure and convey the importance of eliminating technical debt. To laypersons, not geeks. Not enough work here despite its importance. Everyone is instead making arguments for geeks that already get it cuz they're knee deep in the crap or picked the job that didn't have it. Great attempt here: http://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/ http://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is... Tool for metrics here that was interesting. Not tried it, though. http://swreflections.blogspot.com/2012/02/technical-debt-how-much-is-it-really.html http://swreflections.blogspot.com/2012/02/technical-debt-how... " I'm still not sure if I believe the "unlimited downside" idea 100% (because only very few things are truly unlimited), but it's an interesting concept." I just thought it sounded catchy. Not committing to it myself. ;)

by struppi 11y ago

nickpsecurity 11y ago

" Thank you so much for your detailed reply! That's a lot to think about :)" You've very welcome. :) "Thanks for the hints about defects. I like "unacceptable code", but it's probably still a definition not everyone can live with :)" I kind of came up with it off the top of my head. Point is that the code will be rejected on relatively arbitrary criteria. It might be known defects, coding style, what libraries were used... anything. Hard to find a word or phrase covering all that which people will agree with. "Also, CleanRoom is really interesting, but I don't know very much about it and never experienced it." This presentation... http://groups.engin.umd.umich.edu/CIS/course.des/cis376/ppt/lec21.ppt http://groups.engin.umd.umich.edu/CIS/course.des/cis376/ppt/... ...summarizes it for you in about 5 min of reading. The first attempts to make software in a scientific way, engineered software I call it, were done by Margaret Hamilton (founder of our field) at NASA plus academics like Dijkstra and Hoare. They all produced nearly defect-free systems in a systematic, often mathematical way. Harlan Mills took the lessons to industry when developing Cleanroom: a combo of lightweight formal methods, design constraints, spec/code verification, incremental development, and usage-driven testing. He wanted SW products to be as low-defect as HW clean rooms. Result was code at extremely low defect rate that was consistent enough for statistical certification. While popular, Cleanroom teams actually warrantied their software. Altran/Praxis is another company I know that (a) truly engineers software and (b) warranties it at specific defect rates. Defect rates are usually better than the Linux kernel and close to the Space Shuttle's control code. Here's a case study of their Correct by Construction process applied to high-assurance, certificate authority: http://www.anthonyhall.org/c_by_c_secure_system.pdf http://www.anthonyhall.org/c_by_c_secure_system.pdf So, there's you two methods that already maxed out quality (and/or security) on real-world projects. Altran charges an acceptable premium for quality but Cleanroom often cost nothing extra or saved money for same reasons as you article says. Appears the modern programmers still have lessons to learn in software quality from the 1980's. Like I tell people, the old wisdom is often pretty solid even after you fix outdated parts. Our field is just terrible at passing it down. I try to fix that with posts like this so the smart, young people get a boost toward whatever great things they create. Also reduce endless rediscovering of fire and reinventing the wheel. :) "I was thinking about the order of the points a lot, and no particular order seemed really right. It now comes at a point where I think I have established all the preconditions: Speed means lead time, cost depends on speed, high external quality means faster, high internal quality means faster. " I'm going to let you keep working on that formula. You've got the right ingredients. Far as order, there might not be any. Many things in engineering or business are holistic where the parts all feed into each other. The goal is an emergent property of that. So, rather than an order, you'd visualize it like a bubble chart or something that with connections between the components and labels for the effect they have. Just something that's clear that they're all connected, all feed into each other, and ignoring one breaks the process for achieving the goal. Just my dos centimos. "Maybe I'll write another article about how users care about internal quality - Because I've worked in so many legacy code projects that I think I have a good view on that :)" You should. Matter of fact, you should do a lot more work on figuring out how to measure and convey the importance of eliminating technical debt. To laypersons, not geeks. Not enough work here despite its importance. Everyone is instead making arguments for geeks that already get it cuz they're knee deep in the crap or picked the job that didn't have it. Great attempt here: http://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is-doing-about-technical-debt/ http://tech.ticketmaster.com/2015/06/30/what-ticketmaster-is... Tool for metrics here that was interesting. Not tried it, though. http://swreflections.blogspot.com/2012/02/technical-debt-how-much-is-it-really.html http://swreflections.blogspot.com/2012/02/technical-debt-how... " I'm still not sure if I believe the "unlimited downside" idea 100% (because only very few things are truly unlimited), but it's an interesting concept." I just thought it sounded catchy. Not committing to it myself. ;)