« New article on enterprise policy hubs today | Main | Book Review: The Only Sustainable Edge »

The problem with programmers

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: , , , , , , , , ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference The problem with programmers:

» Habits of effective developers from James Taylor's Decision Management
I saw this post by Eileen Yu over on ZDNet Asia - Seven habits of effective developers- in which she discusses an interview with Lee Chuk Munn, a staff engineer at Sun Microsystems Asia-Pacific.I liked the list overall but a... [Read More]


the mad programmer

the problem with programmers....

bite me.

the problem with programmers...are the suits...that just dont get it.

...was a programmer? once a programmer...always...

clearly, you werent...arent.

the real problem is the inability of the suits and programmers to work together effectively (read POINTING SUIT.)
EDITORIAL COMMENT: That, as they say, was my point. Pity you did not read the post carefully enough to notice.


Hi James

The ap is the silver bullet - The programmer is the gun - The project manager pulls the trigger - The busines analyst is the one who aims it.

I note you don't have a category for business analysis (analysts) on this blog and am surpised.

Business analysts are the key to good design. Their analysis of the current state of the business and where it needs to go in the context of the project is critical.

BAs should report in to the business not the IT department. And they should be analytical - a surprisingly rare skill among many of the cadre of BAs out there.

And they should respect and understand the work that programmers do.

And so on.

...You and your readers can contribute to building the BA knowledge base by reading and contributing to the BA wiki project: ...


I agree that it is unpractical to expect programmers to become proffecient in the business in order for them to deliver a succesfull implementation. However, I find that in general, programmers and other IT personnel are much more qualified and adept at analysing and defining processes than are most business personnel. I graduated with a double major in Software Engineering and Business Administration. While the business classes helped to prepare me to understand the real world scenarios I'd be facing when I got out of school, they rarely taught me how to improve or produce change in these environments. On the other hand, while the technical and mathematical content of the engineering courses did not expose me to many real world situations, they did teach me how to define new processe and systems and how to critically analyse and solve problems. There is more to being a succesfull manager or sme than knowing your business well. Sometimes, software development and process improvement require you to step outside of the current domain, out of the processes and systems that you deal with and re-invent and re-engineer. These are skills that few business personnel have and the only way that most organizations have found to mitigate this risk is to lay on the responsability of requirements analysis and process definition on IT personnel. Developers should not have to play the role of analyst, but they are much more fit to do so than are business school graduates and this introduces an inherent risk in the implementation of a BRMS where the business personnel are left to define and implement their business rules and processes autonomously from the IT department who in the end is responsible for managing the information of the organization.


You hit on a good point, and one about which I have tried to blog before ( You need a different perspective to design systems, write code, manage the information. The purpose of a BRMS is not, however, to leave the business to define the rules themselves but to empower them to become true collaborators. Code can ONLY be managed by programmers and will always be regarded as something akin to gobbledegook by most business people. Business rules, in a BRMS, allow you find some common ground between the two. That's why they work.

David Wright

Hey, I already tried ditching programmers back in the 90's with IEF; the damn thing worked too, but couldn't survive the marketplace. I think the problem was that programmers were asked to evaluate the tool and saw that it did generate reasonable code, and killed it as fast as possible; it was like asking the Luddites to evaluate the machines that replaced them.

Hey, I am like most everyone else in this business with any experience, in that I also started as a programmer. However, I saw it was not a stable career and moved up the life-cyle to analysis and requirements and have never regretted it. Sorry programmers, but your domain will continue to be assaulted and reduced. The only good thing is that there will always be a need for some amount of custom coding, but we won't need to increase the number of programmers to do it, so the whole programmer-shortage problem will fade.

The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.