Firstly let me say that not only are some of my best friends programmers but that I have been a programmer, development manager, product manager, architect and methodology author in my career so please don't consider this some marketing guy whining about programmers!
Anyway, I was reading EDS' Next Big Thing blog and saw this post "Is Programming The Problem?" discussing an interview with Bjarne Stroustrup called "The problem with programming". Like Randy Mears at EDS I found the interview interesting. Randy summarized it by saying "some blame goes to programming language complexity, while most goes to our development methods" with which I agree but not, perhaps, for the reasons you might think.
I think the problem is not with programming languages per se but with the idea that programmers should be responsible for coding the behavior of the business, it's business logic or decisions, in the first place.
When Bjarne says that bad programs sometimes show signs that "programmers clearly didn't think deeply about correctness, algorithms, data structures or maintainability" he may be right but I think his comment that "a system just 'sort of evolved' into something minimally acceptable" is closer to the truth. How can we expect a programmer to be both an expert in programming (with all the architectural, design, language and technology skills that implies) and an expert in the business? Clearly we cannot. If we are to build systems that work the way the business needs them to then those who understand the business will have to take a real role in the development of information systems. Otherwise programmers will build what they think is needed and then "sort of evolve" it into something that works. But programmers and those who understand the business have a fundamental difference in perspectives. Unlike Bjarne I don't think that allowing programmers to express "real-world ideas succinctly and affordably" is what makes a language useful, at least not when those real-world ideas are things like "follow the state regulations when approving loans".
Bjarne's brief definition of a good system is "correct, maintainable, and adequately fast" and it's a good definition. It must be noted, though, that "correct" and "maintainable" go together in the sense that code that starts off correct but is not maintainable will rapidly be incorrect. As this kind of change is inevitable systems should be designed, and languages selected, to focus on this maintainability. This focus on maintainability is one of the reasons why business rules can be better than other coding styles. When correctness must be described in business terms, rather than technical ones, then you need languages that enabled what Forrester calls"Collaborative Business Engineering" - an approach where the business and the programmers are working jointly on solving a problem and keeping that solution current rather than the business throwing it over the wall to the programmers. Now there are those that say that requirements are the problem - if we could just get the users to get them right we could build the right system. Personally I call this the requirements tarpit and have blogged before as to why requirements show the problem but aren't the problem.
Anyway, one of Bjarne's solutions is to "use more appropriate design methods, and design for flexibility and for the long haul". I could not agree more and think the evidence that business rules and business rules management systems can address this is compelling. Don't let your programmers write business logic, make your business users do it!
Technorati Tags: BRE, BRMS, business agility, business rules, decision automation, decision service, programmer, programming, requirements, Bjarne Stroustrup
