CASE becomes ALM and consolidates
Developing on a legacy
ALM is one area, at least, where Microsoft is still playing catch-up – most people I meet from Microsoft’s Visual Studio Team System (VSTS) project still seem to think it's cutting code, not managing requirements, that’s really cool. So, when Ian Knox (lead product manager, Visual Studio Team System) let slip to me recently that he considered that everyone else was playing catch-up to Microsoft, I think he meant that its tools were particularly well-made and easy-to-use – we’ll have to see what Tim Anderson thinks when he delivers a review here later this month. However, it seems to me that Microsoft’s VSTS tools are a considerable improvement on what it used to have – and cover more of the lifecycle too. There is even innovation with Domain Specific Languages, although the jury is out on how successful these will be – Jack Greenfield blogs a reprise of some of the discussion here (Grady Booch, of Rational, has some issues here, for example).
So, ALM seems healthy. The big question remaining with ALM for the general programming community, perhaps, is: can you really automate business requirements management, software development and operational support? Surely, it’s all a craft and you just need clever people to make it all work? Well, no doubt a lot of banking back-office staff, for example, thought this way before the IT people automated many of them out of existence. We would be lucky (and probably well hated) if what we did to others couldn’t apply to ourselves.
However, a mantra from the early days of Systems Analysis still applies: “automate the routine and use people to deal with the exceptional”. Perhaps not everyone agrees that there is a routine in software development – here are a couple of quotes from Register readers commenting on IT professionalism: “Programmers have no such book. Every problem is new and different”; “Each job a mechanic does is a series of fixed steps. If you’ve done it once you can do it again. Developers have difficulties because they’re generally creating something new each time - often in a new environment” – but I simply can’t see that a system to, say, manage a doctor’s surgery in Birmingham is very much different in essence to a system used to manage a surgery in Bristol, although each may be coded from scratch by different programmers using different databases and IDEs. Paying to have similar functionality coded from scratch will soon make no sense to the people paying for software to automate their business (perhaps it hasn’t for some time); and software developers will have to keep up.
I see space for some developers writing third generation code for advanced pieces of utility software, to deal with parallel processing and performance bottlenecks, and probably working for the suppliers of databases and application servers. The rest of us will, eventually, move higher up in the ALM stack, analysing requirements, designing architectures, and QAing automated systems against “what the user really wanted”. And we will probably be writing something like UML 2.0 instead of code; writing good UML needs similar skills and disciplines to writing code but works at a higher level…
And I fully expect to hear similar comments to those I heard when I abandoned my roots as an Assembler programmer and moved on to third generation languages, 4GLs and prototype domain specific languages such as SQL; but how many people still write Assembler (or even C) today? Nevertheless, these changes won’t take place tomorrow – one thing experience tells me is that process change moves at the rate people change culture, not at the rate computer chip designers work.
That said, will coding ever really die? Well, not if you’re really, really good at it (I know that we’re all above-average coders just as we’re all above-average car drivers, but I mean blindingly good) or find a backwater which just hasn’t moved with the times. As late as the 1980s, I knew a very clever Australian programmer who made a very good living maintaining Assembler, which hooked into a mainframe OS “feature” (bug) inside a major bank’s back office applications and is probably still doing it; and in the 1990’s I met a programmer who knew nothing about Windows and made a living writing DOS systems that interfaced with Teletext for automotive parts dealers.
But you might be unwise to rely on such undoubted niche opportunities for a career these days. My career advice is to look around the ALM vendors and decide which of them has an offering that matches your way of looking at things – whatever you think of these developments generally, there’s a lot of choice on offer.®
David Norfolk is the author of IT Governance, published by Thorogood. More details here.