From reading that article I can confirm I’ve worked on programming projects that had a Validated, spec everything, someone explicitly rechecks everything, document everything, sign off on everything approach and also projects which had more of that Diet Coke and Pizza feel, and I didn’t even start working until almost 10 years after that article was written. That article allowed me to pull together some disparate points about checking risk management and expressed them clearly, so thank you for posting it.
For your question, I tried to start answering it, but I’m not sure I was able to finish in a timely manner, (The team structure was hard to lay out in text, I feel like a flow chart might have been better) so here is the layout of teams I have so far:
I think you would probably have at least some elements of a hierarchical approach, by trying to break FAI down into smaller categories and assign them each teams, in addition to having a team that checked the integration of the elements itself. And at each step, having a part of the team that both tried to make code for it, and a part of the team that tested the existing codes handling, and then iterating that step, repeatedly, depending on how large the remaining problem space was.
To attempt to give an example, if the first step is to break down FAI into “Values” “Problem Solving” and “Knowledge” (This is just a hypothetical, I’m not proposing this specific split) The Problem Solving team would realize they are going to have to further break down “Problem Solving.” Because the amount of time it would take to test all of the FAI’s problem solving abilities in all fields is far too large. You would also have to have a process to account for “We attempted to break it down into these three things, but now we realize we’re going to need this fourth thing.”
You would then need another overteam for “Well, this particular problem is intractable for now, so can we work on other elements in the mean time and put in some kind of temporary solution?” For instance, if in problem solving, “Black Swan Events” gets it’s own category, the overteam might realize that the overall category is intractable for now, (Because even if you code it to handle Black Swan Events, how could the validation team validate the Black Swans Events code?) and then you might have to say something along the lines of “Well, if we can at least get the FAI to recognize a Black Swan, we can have it call for external help if it sees one, because that is sufficiently better than the existing alternatives even though it clearly isn’t perfect.” or “Damn, there does not seem to be a way to solve this right now, and there isn’t a worthwhile ‘Good Enough’ solution, so we’ll have to put the project on hold until we figure this out.” The overteam would of course also have to have it’s own validation team, which would almost certainly be the most important part, so you would probably want it to be validated again, just to make more sure.
Also, since I just coded that, I should now try to get someone else to validate it before I assume it is correct.
From reading that article I can confirm I’ve worked on programming projects that had a Validated, spec everything, someone explicitly rechecks everything, document everything, sign off on everything approach and also projects which had more of that Diet Coke and Pizza feel, and I didn’t even start working until almost 10 years after that article was written. That article allowed me to pull together some disparate points about checking risk management and expressed them clearly, so thank you for posting it.
For your question, I tried to start answering it, but I’m not sure I was able to finish in a timely manner, (The team structure was hard to lay out in text, I feel like a flow chart might have been better) so here is the layout of teams I have so far:
I think you would probably have at least some elements of a hierarchical approach, by trying to break FAI down into smaller categories and assign them each teams, in addition to having a team that checked the integration of the elements itself. And at each step, having a part of the team that both tried to make code for it, and a part of the team that tested the existing codes handling, and then iterating that step, repeatedly, depending on how large the remaining problem space was.
To attempt to give an example, if the first step is to break down FAI into “Values” “Problem Solving” and “Knowledge” (This is just a hypothetical, I’m not proposing this specific split) The Problem Solving team would realize they are going to have to further break down “Problem Solving.” Because the amount of time it would take to test all of the FAI’s problem solving abilities in all fields is far too large. You would also have to have a process to account for “We attempted to break it down into these three things, but now we realize we’re going to need this fourth thing.”
You would then need another overteam for “Well, this particular problem is intractable for now, so can we work on other elements in the mean time and put in some kind of temporary solution?” For instance, if in problem solving, “Black Swan Events” gets it’s own category, the overteam might realize that the overall category is intractable for now, (Because even if you code it to handle Black Swan Events, how could the validation team validate the Black Swans Events code?) and then you might have to say something along the lines of “Well, if we can at least get the FAI to recognize a Black Swan, we can have it call for external help if it sees one, because that is sufficiently better than the existing alternatives even though it clearly isn’t perfect.” or “Damn, there does not seem to be a way to solve this right now, and there isn’t a worthwhile ‘Good Enough’ solution, so we’ll have to put the project on hold until we figure this out.” The overteam would of course also have to have it’s own validation team, which would almost certainly be the most important part, so you would probably want it to be validated again, just to make more sure.
Also, since I just coded that, I should now try to get someone else to validate it before I assume it is correct.