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!
Comments on this entry are closed.
Great post James! I wholeheartedly agree that you need someone with a strong business presence and some technical know-how. This is also very difficult to find. I have worked with developers (JDE/E1 and Mainframe) that can code the heck out of their program, but it’s not what the business needs or wants. I find developers are not in tune with what the business really needs.
I have also worked with Business Systems Analyst’s that are excellent and really fill the void between business owner and developer. They are hard to find and often overworked because they are good.
You might want to have a look at what Charles Simonyi at Intentional Software is trying to do.
I think that Tony Rose’s comments are right on. The source of the problem that has arrisen over the past 15 years is that the evolution of “Business Systems Analyist” has become just a programmer with lots of progroming experience. It seems to be assumed that really good programmers suddenly become business systems specialists because they programmed business systems for 5 years. So..they continue their process in using programing to solve issues rather than looking at the business processes. (because that is what got them their promotion.) Their used to be a group of really great Business Systems Anaylists, they were called Industrail Engineers. They lived and breathed improvements to business systems and had all the tools to address them. However, over the years, these departments have been eliminated. The result is what you see today.