ProjectEuler Problem 76 illustrating Toyota’s Woes
The above is my initial attempt to solve Project Euler problem 76 in Java. It’s a straightforward, easy to understand and read java class designed to count the number of unique ways to add two or more numbers and get 100. disregarding whitespace and comments it has twelve lines, four actions, two decisions and an iterator, making it a very small program.
It’s also wrong.
If run, the numbers generated quickly blow up beyond counting and FAR beyond reason. It took me the better part of a day to figure out the problem (initially, I thought it was due to the types of variables I was using and played with the BigInteger class for a while before deciding that my results were simply ridiculous. I finally played through the assumptions in my head to the point where I realized what my mistake was.
Here is the correct version:
This code recurses through the possible ways of adding numbers together and, when it reaches 100, counts one. The previous one, did the same thing, but for each sum of numbers adding up to anything LESS than 100, instead of passing the most current sum forward, ADDED it to the previous sum. This is because in my head, I just KNEW that what I wanted to do was add one to the count when I had an iteration that reached 100 and, when it wasn’t, I wanted to add up all the successful sums on the other branches of the tree. The proper way of thinking of it is to go through the tree “picking” the points that reached 100.
Remember, I messed this one up and it only had 12 distinct lines of code.
Now consider that The code running – and interacting – in a Toyota can be more than 100 MILLION lines of code.
CNET discusses this too:
“We’re not talking about tiny applications here but a huge amount of code. Code size matters because the more code you have, the harder it is to test all of its behaviors. That involves driving the code towards doing things that are unusual or perhaps testing it with different timing, different ordering of events,” he said.
Coverity maintains that the most common problem in large software systems is integrating all of the pieces together.
“You may have little individual components that do their jobs well but when you put them all together, they may not interoperate in a way that is reliable. These code bases are not sequestered from each other, they’re all interoperable,” said Peterson. “And what happens when you start to glue together 20 or 30 subsystems inside of an automobile–the different combinations between these systems start to operate in very unexpected ways.”
And, of course, you do NOT want unexpected things happening when you are driving in the rain down a curvy highway at 85 miles per hour…
Oh yeah, this problem with Toyotas? It, or similar issues, can happen to pretty much any reasonably new car on the road. And according to the above article, much of the code on the road right now would, by many measures, be properly classified as being still in beta.