The evolution of systems development methods and tools can be usefully mapped against the Business-IT Maturity model in order to better understand the challenges of getting to Level 3.  Programming languages have evolved from 1st generation (e.g., Machine Code) through 2nd generation (e.g., Assembler) to 3rd generation (e.g., COBOL, PL/1) to 4th generation (e.g., Mark IV, FOCUS, and debatably RPGII) to Application and system Generators that automatically produce program code from high-level models and specifications.  What’s important about the evolution of the programming paradigm are the major (sometimes 180 degree) shifts that it implies.  

For example, moving from 1st, 2nd, and 3rd generation languages means shifting from:

• Procedural (focus on step by step program instructions) to object oriented (focus on ‘objects’ and their interactions) programming
• Write program code to reuse program code
• Programming as writing to programming as modeling
• Waterfall systems development life cycle (SDLC) to rapid, iterative development
• Systems development as an IT job to systems development as a business-IT collaboration
• Requirements to business outcomes driven systems
• Fish for them, to teach them to fish

For IT shops that have been around 15 years or more, this shift to so-called contemporary systems development technologies is not just a change of tools – the carpenter, for example, moving from brace and bit to electric drill – it represents a shift in paradigm – from constructing the chair from planks of wood, to fabricating it in a plastic injection mold.  The competencies are very different – think master cabinet maker versus manufacturing engineer.  This is not just a matter of skills.  Any COBOL programmer can, given time and motivation, learn any procedural computer language.  It is more one of innate abilities and motivations.  If my mission is to write code, I have a hard time getting juiced up for the day when success is measured not by written code, but by other people’s code reduced.  I have a hard time getting excited about a day locked in a conference room with a business executive doing process modeling and simulation.

A personal story to further illustrate my point.  As a kid (this was early 1950′s), I was an avid electronics hobbyist.  I used to build amplifiers and other electronics stuff.  As a young teenager, I made money by fixing friends radios and televisions.  I loved the whole gestalt of the workbench, smell of a hot soldering iron, the glow of a vacuum tube, and hum of a power supply.   I became aware of computers through hobby magazines, and began to build them.  My career ambition became crystal clear – to become a computer hardware engineer.  Fast foreword 10 years – fresh out of university with an Electrical Engineering degree I landed my first job as a computer designer.  In the meantime, the role had shifted from raw electronics to boolean logic and integrated circuits.  Design shifted from an exercise in Kirchoff’s law to an exercise in logic – once the logic diagrams were laid out, it was simply a matter of combing through Signetics and Texas Instruments catalogs of Integrated Circuits, finding the right chips, laying out the printed circuit layout, and testing the end result.  No soldering iron, no visceral feel of the vacuum tube, no real sense of “electronics” as I had cherished it as a kid.  After 6 months of sitting at a drawing board laying out logic diagrams all day, I resigned from my dream career, and moved into software engineering.

Transitioning many of our traditional, up-through-the-ranks computer programmers to be the systems engineers so essential to Level 3 IT capability is going to be a tough journey – and a potential sticking point for those who think is all just programming!