JT on EDM

There was more discussion in the blogosphere about the James McGovern COBOL is Evil post – COBOL is not evil, but COBOL programmers are. Now I already posted a response to James’ post (Why don’t you replace COBOL with something useful – not Java) but this new post made me think. I should 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!

Some time ago Bjarne Stroustrup was interviewed in “The problem with programming” and he made some good points. 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. Not so much that COBOL programmers are evil – all programmers (of a certain mindset) are evil.

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 written 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!