Long ago, in a land now distant to me, I worked for a very successful company.
They were the kind of company that wasn't successful because they were good at software development. They were good at something else and they had to do some software development to make that offering in the modern era.
I was brought into one team by a friend of mine in order to change their thinking. Years later, I heard they still reference me as the reason why they write tests first.
"He came down from the mountains and made us write our test first," they'd say. "He had a beard and everything."
For almost the entire time I worked at this company and on that team, there was one problem they just couldn't seem to lick. It had to do with processing a large body of data. These days there are tools that really are tuned to that kind of problem but, back then, you wrote your solutions yourself.
They struggled and struggled with this problem. They were trying to write a stored procedure to solve it and that procedure took two days to run.
Two days.
After months of watching them struggle, I said "Why don't you let me take a crack at it?"
"Oh yeah," the manager replied. "You did some database work, didn't you."
"I did," I said, "but I'm going to solve this problem with a program not a database."
Everyone was skeptical. How could it be that you could process all those records in code faster than with a database. Databases have the word "data" right in their name!
With a friend/pair-partner, I spent a week developing an object-oriented solution to the requirements that had been given to the guy doing the database work.
At the end of the week, I had a simple solution that worked exactly as specified and worked almost as well as the product owner wanted.
It took less than a day to implement the new, previously-unexpressed requirements.
It wasn't just that the object-oriented solution was faster to develop. It executed more quickly, too. When we shipped it, it could process the entire data set correctly in less than forty-five minutes. That may seem slow but, for the time and compared to the stored-procedure solution, it was very fast.
The person who had committed himself to the database solution came to me to talk about what happened. He chose a database to solve the problem, which was the correct tool. I chose an object-oriented program to solve the problem, which was the incorrect tool. Yet my solution worked and was almost fifty times as fast as his solution, which failed.
He wanted to know how this was possible and my answer was another question: "How did you decide that the database was the right tool and the object-oriented program was the wrong tool."
His answer was that industry standards and best practices told him so.
"So there you go," I said.
