Business-Suitable Programming Tools

I'm a Technical Guy. I'd been an R&D programmer for most of my working life, but for some reason for the last few years I've become more passionate about Business-Suitable Programming than about Techno-Guru Programming.  Back in the day I was once enamored with the nuances of graphics rendering techniques, communications protocols, object-oriented programming languages and object-relational persistence mechanisms... but nowadays I find myself passionately wanting to help "average" people learn to write the programs that make their jobs (and their lives) a little bit easier, and I really couldn't care less about whether or not "Java implements closures".

Can Business Guys Program?

Programming is the act of transforming requirements into something that a computer can execute... so if the software's requirements are highly technical it stands to reason that a highly technical person will be the best programmer for the job.

But what if the software's requirements are primarily Business requirements?

Many will argue that Business Guys will never be able to create non-trivial software without the help of Technical Guys... and there is a lot of truth in those arguments... but there's also a lot of falseness in those arguments (many software development tasks aren't technical at all).

Business Guys ( aka Subject Matter Experts) generally understand the requirements of their Businesses a whole lot better than Technical Guys.
When Technical Guys implement Business Requirements, they generally have to spend a lot of time gathering up what the Business Guys know and translating that information into something that they can work with.  Sometimes (way too often actually) a lot gets lost in that translation and the software is a flop.

It stands to reason that Business Guys should be better Business Programmers than Technical Guys - they can more accurately transform Business requirements into code than Technical Guys can - but that's just theory unless they have the right tools to accomplish the job - and those tools are sadly lacking.

There's the million dollar question: What are the right programming tools for Business Guys?  What programming tools are Business Suitable?

To answer these questions we need to think about what makes a Business Guy's programming different from a Technical Guy's programming.

Business Guys are Occasional Programmers

The typical Technical Guy's IDE (Integrated Development Environment) and the typical Technical Guys programming language of choice (Java, C#, etc.) really aren't Business Suitable programming tools... because these tools were developed by folks whose primary jobs are to develop software... and Business Guys are occasional programmers (at most).

Business Guys don't develop software for a living... They may go for months or years without even thinking about creating or modifying software - but when they need to "program" they will generally need to get the program written and deployed very quickly.

Business Guys can be taught to use sophisticated programming tools (I've done it)... but they probably won't stay proficient with those tools.  They will forget things.  Their "programming skills" will get rusty over time... so Business Suitable programming tools need to take this into account.

Business Suitable programming tools are designed for people who don't program all the time.

Use the Business Guys' Terms

It's a no-brainer, but Business Suitable programming should use Business Suitable terms.

For example, Business Guys tend to spend more time working with "Money" than working with "Decimals", so why make worry about conversion from one to another?  Why not just have "Money" as a key concept of the programming language?

Money is a simple (but pervasive) example of what to look for, but in general the closer the programming language is to the Business Domain, the easier it will be for the Business Guy to program.

Put the "Code" where the Business Guys will look for it

Business Suitable tools need to rely on the Business Guy's knowledge of the problem to lead them to the "code" that solves the problem.  Rather than relying on "class hierarchies"  or "package names", organize the programming artifacts in a manner that makes sense to the Business Guys (like BPM suites that let you to navigate to Screens and underlying Code from the Process Diagrams).

The Business Guy's "coding skills" are bound to get rusty, but their Business Knowledge won't - Leverage knowledge of the business problem to help Business Guys navigate the "code base", and they'll get back up to speed very quickly when they need to.

Where Did We Go Wrong?

I've always wondered what happened after COBOL... Obviously we've always understood the need for a Business Suitable programming language, but after COBOL it seems like Business became a dirty word.  Pascal, C, C++, Java, JavaScript... Where's Business in that "mainstream" legacy?  If there's a Business focussed language out there that 80% of programmers have heard of (other than COBOL), I'd be very surprised.

Business Guys Outnumber Us

I saw a very interesting slide a few weeks ago at our Lombardi (an IBM Company) yearly kickoff conference depicting the ratio of Business Guys (Knowledge Workers) to Technical Guys (Java Developers) in a typical enterprise... I'm pretty sure the numbers were pulled out of the air, but they seem right - about 1000 Business Guys per Technical Guy.

If this ratio of Business Guys to Technical Guys is anywhere near close to accurate, then what do you think is a better approach to "Saving the World"?

1. Create better tools for the Technical Guys so they can service 1000 Business Guys
2. Create more Business Suitable tools so the Technical Guys can focus where they need to.

I'm voting for option 2.