I had lunch today with a good colleague who's a Rules Guy... Shocking, I know, to think of a Process Guy having lunch with a Rules Guy... but it's good to socialize with these folks in the hope that they'll wise up and "see the light" ;-)
Process Guys and Rules Guys have a common problem. Our products can change the world... Improving efficiency, cutting through bottle-necks, eliminating fraud and waste... but only if governments make widespread use of them. Governments kind of like the idea of using our tools, but they can't use our tools unless they can find a lot of people who know how to use our tools. A lot of people.
Every Federal, State, County and City government needs our tools. Big, huge or tiny... it doesn't matter the scale... governments need our tools to manage their procedures and policies - and they need people who know how to use our tools.
My colleague and I live in Santa Fe, New Mexico... not the smallest state capital, but by far not the largest. Not the worst state government, but not the most stellar either. I'm convinced that widespread use of Business Process Management and Business Rules systems within our state government could help dramatically improve our state's operations... but there simply aren't enough BPM and BRM folks in the state to tackle the problems. Case in point, there's been an unfilled BPM consultant posting on the Santa Fe Craigslist for months.
I travel the world helping people master our BPM suite. I would never say that there's "no coding required"... that's simply not true... but the level of programming skill that's required is way below that needed for truly custom programming. You need to know some JavaScript and some SQL, and it really helps if you know a bit of HTML and how to parse XML, but you don't need much more than that. Our BPM suite handles most of the heavy lifting on "the front end" of your processes (Truth in advertising caveat: Your traditional IT folks still need to do your back-end integrations).
Folks who have the right aptitude can pick up the skills that they need in a very short time. Months, not years... less if they have the right guidance. I know because I've helped them.
The problem is one of classic "Chicken and Egg". I'd love to teach a class at our local community college (the Santa Fe Community College is awesome), but nobody in their right mind would sign up for the course. There's no work for the graduate of a BPM program here in town.
We could solve that problem by convincing the State to launch some BPM projects... but they'd be insane to do so... There aren't any BPM folks available to staff those projects.
This "Chicken and Egg" conundrum isn't unique to Santa Fe. Off the top of my head I can only think of a dozen cities in the country where you wouldn't have a problem staffing a BPM or BRM project. Business programmers are a rare breed outside the urban centers... as I imagine database programmers were a generation ago.
We can fix that. We can close "the Business Programmer Gap"... but only if the "Chicken" or the "Egg" goes first.
Friday, October 15, 2010
Friday, October 01, 2010
Why Occasional Programmers Suck
The world is full of tools for folks who write programs for a living. Lots and lots of tools.
The world has very few tools for folks who only program on occasion... and in my less than humble opinion this is why many people who ought to write their own programs don't even try to.
A program is simply the outcome when a set of requirements (something you want a computer to do) is translated into instructions that a computer can execute. Over the years, our expectations of what a computer should be able to do have vastly increased in complexity... Once we thought it was cool that we could "draw" faces with a computer. Now we expect the computer to recognize faces in a photograph.
The software that performs these functions is wildly complex, composed of millions of "lines of code"... and that's led most people to believe that all software has to be wildly complex and hard to write... but that's not the case. The "hard parts", and there are many "hard parts" can be packaged as "black boxes" with relatively straight forward "interfaces" to expose functionality for the occasional programmers to use. If the functionality of the "box" maps pretty closely to the requirements of what we want the computer to do, then it should be pretty easy for us to write a program.
This was the promise of Object Oriented Programming. Build a lot of black boxes with well defined interfaces and then put them together to create whatever program you need.
Great idea, but we got it wrong. We designed languages for building our black boxes, and then we convinced ourselves that we should use those same languages to connect our black boxes together to create useful programs. Bad mistake. Really, really bad mistake.
Using the same language for building boxes and for connecting boxes allowed the experienced programmers to pretty much ignore the way that the black boxes were supposed to be used. The "code" they wrote to put the boxes together was pretty much as unintelligible to the occasional programmers as the code that was used to build the boxes themselves. It all pretty much looks like Greek or Swahili to an occasional programmer (who can't read either Greek or Swahili).
Imagine the distress of the occasional programmer who has the gall to try to build something using the boxes created by a master programmer... To even read the master programmer's code the poor novice has to learn the intricacies of a dozen or so esoteric topics. It's like having to understand the ignition sequence of the cylinders in your car's engine before you can turn the key. No wonder they're terrible programmers.
It's time for a wakeup call in the world of programming... Our collective need for custom programs is growing at a much greater rate than our supply of master programmers. We can either continue to focus on tools for these master programmers - to make them even more productive - or we can figure out how to empower those occasional programmers to do it for themselves.
If we don't build tools that are targeted at the "occasional" audience, then nothing will change. Occasional programmers will continue to suck.
The world has very few tools for folks who only program on occasion... and in my less than humble opinion this is why many people who ought to write their own programs don't even try to.
A program is simply the outcome when a set of requirements (something you want a computer to do) is translated into instructions that a computer can execute. Over the years, our expectations of what a computer should be able to do have vastly increased in complexity... Once we thought it was cool that we could "draw" faces with a computer. Now we expect the computer to recognize faces in a photograph.
The software that performs these functions is wildly complex, composed of millions of "lines of code"... and that's led most people to believe that all software has to be wildly complex and hard to write... but that's not the case. The "hard parts", and there are many "hard parts" can be packaged as "black boxes" with relatively straight forward "interfaces" to expose functionality for the occasional programmers to use. If the functionality of the "box" maps pretty closely to the requirements of what we want the computer to do, then it should be pretty easy for us to write a program.
This was the promise of Object Oriented Programming. Build a lot of black boxes with well defined interfaces and then put them together to create whatever program you need.
Great idea, but we got it wrong. We designed languages for building our black boxes, and then we convinced ourselves that we should use those same languages to connect our black boxes together to create useful programs. Bad mistake. Really, really bad mistake.
Using the same language for building boxes and for connecting boxes allowed the experienced programmers to pretty much ignore the way that the black boxes were supposed to be used. The "code" they wrote to put the boxes together was pretty much as unintelligible to the occasional programmers as the code that was used to build the boxes themselves. It all pretty much looks like Greek or Swahili to an occasional programmer (who can't read either Greek or Swahili).
Imagine the distress of the occasional programmer who has the gall to try to build something using the boxes created by a master programmer... To even read the master programmer's code the poor novice has to learn the intricacies of a dozen or so esoteric topics. It's like having to understand the ignition sequence of the cylinders in your car's engine before you can turn the key. No wonder they're terrible programmers.
It's time for a wakeup call in the world of programming... Our collective need for custom programs is growing at a much greater rate than our supply of master programmers. We can either continue to focus on tools for these master programmers - to make them even more productive - or we can figure out how to empower those occasional programmers to do it for themselves.
If we don't build tools that are targeted at the "occasional" audience, then nothing will change. Occasional programmers will continue to suck.
Subscribe to:
Posts (Atom)
