There is an overwhelming desire by non-programming business people to reduce programming to something they understand better. Not knowing how to program, they have to grasp for analogies like building a house, a bridge or some other large engineering product.
The problem with this is that every large development project I have seen on included a large element of what is really R&D. Most of the engineering around came in the from network admins, DBAs and sysadmins and, most of all, compilers. To roll with the analogy, the development team was designing new studs, beams, screws, and other widgets, to be produced by a (zero cost!) digital factory and later installed by a team of helpers.
This perception gap leads to all sorts of dysfunctional behavior and game playing on both sides. The example you see here is like working extremely hard to boil down your R&D to the equivalent of a one day high school lab, and then staging a contest. It will definitely give you some information, but won't solve the original problem.
I like to explain programming by comparing it to writing a book.
You can't change the plot-lines overnight without having to throw away a few chapters, as well does the plot always have an impact on the story that builds up to it.
Starting to write a book without a good grasp of what story you want to write will probably just be a time-suck.
Both are a produce of intellectual activity and require adequate understanding of the goal in order to streamline the product.
Comments
There is an overwhelming desire by non-programming business people to reduce programming to something they understand better. Not knowing how to program, they have to grasp for analogies like building a house, a bridge or some other large engineering product.
The problem with this is that every large development project I have seen on included a large element of what is really R&D. Most of the engineering around came in the from network admins, DBAs and sysadmins and, most of all, compilers. To roll with the analogy, the development team was designing new studs, beams, screws, and other widgets, to be produced by a (zero cost!) digital factory and later installed by a team of helpers.
This perception gap leads to all sorts of dysfunctional behavior and game playing on both sides. The example you see here is like working extremely hard to boil down your R&D to the equivalent of a one day high school lab, and then staging a contest. It will definitely give you some information, but won't solve the original problem.
I like to explain programming by comparing it to writing a book. You can't change the plot-lines overnight without having to throw away a few chapters, as well does the plot always have an impact on the story that builds up to it. Starting to write a book without a good grasp of what story you want to write will probably just be a time-suck.
Both are a produce of intellectual activity and require adequate understanding of the goal in order to streamline the product.