Like many of you, I suspect, I found Awaiting the Day When Everyone Writes Software (you may need to register) in the New York Times interesting.
While I hate to criticize someone like Charles Simonyi (who has brought to market much more successful software than I have), I find the thrust of his argument disturbing.
The article describes programmers bluntly:
Programmers don’t know what a computer user wants because they spend their days interacting with machines. They hunch over keyboards, pecking out individual lines of code in esoteric programming languages, like medieval monks laboring over illustrated manuscripts
I think this is a little harsh, though I agree there is a problem with programmers, or more accurately with our expectations of them. Why should we assume they know how to make the computer do what we need and that they can understand our business? Is this even a reasonable expectation? Simonyi’s idea of intentional programming “in which programmers would talk to machines as little as possible. Instead, they would concentrate on capturing the intentions of computer users” does not, to my mind, alter this core problem. No matter how good the abstractions, the assumption that programmers should implement the logic that represents the business seems to me to be flawed – programmers and business people have a different perspective and this should be exploited not bridged. You want programmers to apply their unique skills (abstraction, technology know-how etc) while allowing business users to manage how the system implements their business. Now perhaps his software will be so good that “everyone writes software”. But that assumes that business people want to write software when, in fact, most business users don’t want to write code (or maintain rules for that matter).
So if business users do not want to write code, and programmers are challenged to write the code that embodies the way the business “thinks”, what’s the answer?
I saw an article on SandHill.com recently (Unraveling the Mystery of Software Development Success) that showed the project failure trend graph that I have reproduced above. As you can see, the rate of failures due to all causes is declining steadily and converging on the failures due only to problems with requirements. Pretty soon, it appears, all the problems with be with requirements. The problem then is not that programmers cannot write bug-free code in the general case but that it is hard to write code that correctly implements requirements.
My own experience is that it is not requirements like “complete transactions in n ms” or “support a thin client” that cause problems but those like “ensure transactions are compliant with federal law” or “apply current marketing promotions correctly”. The reason these cause problems is that they are not really requirements! They are rules and using business rules can fix this requirements mess. In addition, it seems to me that an issue that must be addressed is that of application maintenance – the ongoing changes that are needed to the logic in a system as the business (and the world) changes. It is this constant editing and patching that destabilizes code but the proper use of existing technology allows much more effective management of application maintenance.
Back to the article. It goes on to say:
Intentional programming has three great advantages: The people who design a program are the ones who understand the task that needs to be automated; that design can be manipulated simply and directly, rather than by rewriting arcane computer code; and human programmers do not generate the final software code, thus reducing bugs and other errors.
If these are the things that worry you, don’t wait for Mr Simonyi.
1. Business rules technology allows those who understand the business to write and, more importantly, manage the rules within their information systems.
2. Business rules can be manipulated simply and directly, especially when templates are used to control the interact and make it fit the business user’s mindset, and no arcane code is required.
3. As someone once said, “there is only one kind of error and it’s a human error” – humans will write the software that generates the final code so it too will have bugs.
As noted above, most of the problems in systems are now caused by issues of implementing rules and these are not solved by generation of code.
The systems you have today have problems but plenty of technology exists that already works and is ideal for building systems that are “smart enough”. Maybe I should write a book on this…
Digg
Reddit
Furl Bookmark murdok:
VP of Product Marketing with a passion for the technologies of decision automation. 15 years designing, developing, releasing and marketing advanced enterprise software platforms and development tools. Across the board experience in software development, engineering and product management and product marketing.
http://www.edmblog.com
