Proofs by induction and real-world business needs
While I was a young and eager undergraduate computer science student, I was taught the method of proving things by induction. Basically, it's a way of showing that something is true for some simple cases, and then showing how it can be true for more complicated cases. There are two major parts to it: prove that the base case works, and prove that the inductive case works.
I see some applications of that kind of thinking in everyday business. Just because I can manage documents on my own doesn't mean that the way I do things will scale to other people. So, to build a solution that grows with the business, I'd have to show first that it works for me, and then assuming it works for X people, show that it will still work when X+1 people are in the picture.
The thing with most inductive proofs is that they show that something is true, or if we map it tightly, it would show that things are possible in business -- that something is computable and knowable. But in real-world concerns, efficiency is a big factor: while it's necessary to show that some method or process works, it is not sufficient. We've got to show that it's efficient, too. (Or in other words, "Duh! We know it's possible. I'm concerned with how quickly and cheaply can we do it.") So, I'd have to show that something works and is efficient for me, and then that if it works and it's efficient for X number of people involved, it will still be efficient for X+1 people.
Additionally, the method or process that we try to prove by induction would probably look like a step function to handle different domains. The reason for this is that a group of five people is going to present a different kind of situation than a group of 100 people, which will in turn be much different from managing an organization of 10,000.
Note to self: when trying to come up with a new solution, come up with something that looks like a step function, with different methods for different points in an input domain, and prove that it works and that it's efficient.
I see some applications of that kind of thinking in everyday business. Just because I can manage documents on my own doesn't mean that the way I do things will scale to other people. So, to build a solution that grows with the business, I'd have to show first that it works for me, and then assuming it works for X people, show that it will still work when X+1 people are in the picture.
The thing with most inductive proofs is that they show that something is true, or if we map it tightly, it would show that things are possible in business -- that something is computable and knowable. But in real-world concerns, efficiency is a big factor: while it's necessary to show that some method or process works, it is not sufficient. We've got to show that it's efficient, too. (Or in other words, "Duh! We know it's possible. I'm concerned with how quickly and cheaply can we do it.") So, I'd have to show that something works and is efficient for me, and then that if it works and it's efficient for X number of people involved, it will still be efficient for X+1 people.
Additionally, the method or process that we try to prove by induction would probably look like a step function to handle different domains. The reason for this is that a group of five people is going to present a different kind of situation than a group of 100 people, which will in turn be much different from managing an organization of 10,000.
Note to self: when trying to come up with a new solution, come up with something that looks like a step function, with different methods for different points in an input domain, and prove that it works and that it's efficient.