A few weeks ago, I read this post about something called Duck Programming, and it rang a few bells.
I've run across a number of these systems in my career,and each has proven to be an abject failure. It is simply not viable to make a complex system totally flexible without programming in some form.
The first system I ran into this was one for replacing single-purpose cellphone provider consoles in stores selling cellphones. The goal of the system was to interface with the store's systems to provide all the options to sell the service without requiring a special-purpose console. It was not simple, but we were well on the way to having this when we ran into the bete noire of cell phone sales - the service plans options.
It seems that at the time, all the cellphone service companies allowed their salespeople to define almost anything as a package, to allow them to make sales. So even though I could not get just call forwarding as an option, a salesman could decide to offer just call forwarding to a customer if the salesman thought it was necessary to make the sale. So every possible option had to be allowed, but only if it was defined from the cellphone service side. And it had to be simple to set up. No programming necessary.
Needless to say, we did not succeed.
The second time I saw this, it was a special-purpose language to control telephone switches, that was supposed to not require programming. It didn't require programming, but required you understand trees and stacks, which meant that you had to have taken programming classes to get everything right. We ended up replacing it with a database and C, which had the added benefit of allowing us to hire programmers from almost anywhere, instead of those who had happened to work in that system previously.
The third time was an attempt to replace a complex control system that had 4 main sections of data, each of which had numerous relationships, with a key:value store. Everything was a tuple, and the keys connected everything in great transitive chains that taxed the system just to get the basic data out.
It failed as well.
I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them.
I've run across a number of these systems in my career,and each has proven to be an abject failure. It is simply not viable to make a complex system totally flexible without programming in some form.
The first system I ran into this was one for replacing single-purpose cellphone provider consoles in stores selling cellphones. The goal of the system was to interface with the store's systems to provide all the options to sell the service without requiring a special-purpose console. It was not simple, but we were well on the way to having this when we ran into the bete noire of cell phone sales - the service plans options.
It seems that at the time, all the cellphone service companies allowed their salespeople to define almost anything as a package, to allow them to make sales. So even though I could not get just call forwarding as an option, a salesman could decide to offer just call forwarding to a customer if the salesman thought it was necessary to make the sale. So every possible option had to be allowed, but only if it was defined from the cellphone service side. And it had to be simple to set up. No programming necessary.
Needless to say, we did not succeed.
The second time I saw this, it was a special-purpose language to control telephone switches, that was supposed to not require programming. It didn't require programming, but required you understand trees and stacks, which meant that you had to have taken programming classes to get everything right. We ended up replacing it with a database and C, which had the added benefit of allowing us to hire programmers from almost anywhere, instead of those who had happened to work in that system previously.
The third time was an attempt to replace a complex control system that had 4 main sections of data, each of which had numerous relationships, with a key:value store. Everything was a tuple, and the keys connected everything in great transitive chains that taxed the system just to get the basic data out.
It failed as well.
I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them.
No comments:
Post a Comment