An over-quoted but appropriate exchange:
Gregory (Scotland Yard detective): “Is there any other point to which you would wish to draw my attention?”
Sherlock Holmes: “To the curious incident of the dog in the night-time.”
Gregory: “The dog did nothing in the night-time.”
Holmes: “That was the curious incident.”
– Silver Blaze, Sir Arthur Conan Doyle
I’m not Sherlock Holmes, and night-time or otherwise, KJR’s subscribers did respond to last week’s column on Service Oriented Architecture (SOA) in a fair number of Comments and e-mails.
The dog that didn’t bark was the community of SOA proponents — developers in the IT trenches who use it and like it.
The only favorable remarks I received came from SOA vendors. These were people I know and respect, providing informed technical commentary, not public relations foggery. And even they did not dispute the article’s two key points: (1) If you disagree with SOA’s design philosophy you’re still stuck with the SOA language set for long-lived applications; and (2) when you compare these languages to high-programmer-productivity development environments like PowerBuilder and Delphi, you’ll be seriously disappointed.
This might mean SOA is nothing but overblown hype, and KJR’s enlightened subscribership sees right through it. It might mean those who don’t like something are more likely to write than those who do.
It also might mean you who read these words are obsolete curmudgeons who need to get with the program but aren’t doing so.
Nah, that can’t be it.
Getting back to the point that matters — programmer productivity — it just might be that, as Pogo said so many years ago, “We are surrounded by insurmountable opportunity,” and (of course), “We have met the enemy, and he is us.”
We’re surrounded by the tools we need to make any and all languages high-productivity languages (the insurmountable opportunity). The biggest stumbling block (our enemy) is lack of will.
Here’s what I mean.
English is a high-productivity language. Writers can use it to efficiently express whatever concept they want to explain. Ignore, for the moment, the strangeness and exceptions that come from its having melded so many source languages and instead focus on the main event: A vast vocabulary of more than a million words that can be strung together according to consistent grammatical rules (notwithstanding their inconsistent instantiations and curious conjugations) to express an inexpressibly large number of potential meanings.
Whatever you want to say you can say. It might be wrong; that’s a different matter.
A data point: Early in my programming career, a friend asked me for a favor. Every day a member of his staff took a stack of punch cards and used a ten-key calculator to total the amounts printed on them. “How hard would it be to write a program that could do this for us?” he asked me.
I wrote a four-line SAS program to do the job. It took me a minute to write, five to test, and an hour to put into production. My friend was effusive in his thanks. A month later, he was still excited about it.
In COBOL the same project would have taken a day or two. SAS provided a richer vocabulary for expressing what a computer should do than COBOL.
That’s the point. Except for designing data-entry screens and complex reports, where there’s no substitute for a visual environment, the key to developer productivity is a rich vocabulary.
A rich vocabulary is why, in English, I can say “airport” instead of “a place for airplanes to take off and land along with the buildings and supporting infrastructure necessary to maintain and refuel them, and the buildings and supporting infrastructure needed to get passengers and their luggage on and off of the airplanes.”
A rich vocabulary is why, in SAS, I could write “PROC TABULATE; BY DEPARTMENT;” instead of a far longer equivalent collection of Dick-and-Jane-level COBOL words.
It’s what we mean when we talk about re-usable business logic, only “re-usable business logic” sounds like an easily-solved problem. “Rich vocabulary” makes the challenge clear.
Any of the languages we use will let us develop whatever rich vocabulary we need to make developers as highly productive as we might want.
With one restriction, which English also illustrates: For competent writers a dictionary and thesaurus are used occasionally, not for every word choice.
The same is true for competent developers: In order to enjoy the benefits of a rich vocabulary, they must first learn the words.
And you have to invest enough of their time to let them do so.
Have you ever noticed that the richer the vocablulary and the higher the level of abstraction supported, then the greater the requirement that the person using that vocabulary understands not only the vocabulary but also what you’re trying to make happen? In translation, the richer vocabulary requires the user to be stronger at analysis and problem specification … and forgive me, but it seems that a large percentage of those who learned to program based upon PC centric tools and problem sets seem to have developed very narrow and limited understanding of complex business problems.
Where I sit, programmers don’t get uninterrupted time to put together good programs. They are expected to multi-task, where programming is it self a multi-tasking activity. Add office environments where programmers are out in the open and everything that occurs in the area is a possible distraction and it’s no wonder they aren’t very productive.
I find I spend a lot of time, not at the high-level design, but figuring out how to get around some limitation – things that should work but don’t. An additional problem I face is that each programming language I deal with has it’s own idiosyncracies – and anyone who was taught programming or has programmed for more than a year has run across things that used to work in one way in one language that no longer work that way because you are working in a different language. I believe programming languages are changing and coming in and out of favor faster than they used to – but maybe that’s my age speaking.
Another piece of the puzzle – how much time do you get to work with fresh material and how much time to do you spend trying to figure out what someone else did before you can add your tiny piece. Writing a new program is much easier than trying to figure out what was going on in someone elses head (even if that someone else was you a few months ago 😉 and how to deal with the limitations that it puts in your way.
I also spend a lot of time dealing, not with the bulk of the data, but how to handle the exceptions – that date field that includes dashes, the number field where someone put in commas, the name field that’s blank, the blank line in the middle of the datastream, etc. Less discipline is expected of the user, and anarchy is now a given, so more programming is required on the back end.
More and more features are expected. What happened to the simple report on green bar? Now users want bold titles, colored columns, a graph, and the ability to export it all to MS Excel, MS PowerPoint, MS Word, Adobe PDF, or a web page – and that web page is no longer static, it has to be interactive to be able to drill down to the details.
In my area, programmers used to get specifications that were almost flowcharts and the person that wrote the specification tested the code. Now they have to listen to the user and write the code from scratch, then test the code. Any guesses why their productivity might have not increased over the years?
I think that programmer productivity IS a vocabulary problem. The languages change too fast for someone to be a true expert in any version other than the one or two he/she is working in. As an example, look at what Microsoft has done for database access since the early VB days … their model for database access changes every 2-3 years. Each time, the change is lauded because it will make something better. But what it does is make the developers have to re-learn how best to do a database task. Then, there is the issue of supporting or upgrading the applications that use the older methods. The vocabulary changes too often.
Thanks for mentioning Powerbuilder. Currently my shop is moving towards multi-layered open-source java-based development tools that are requiring my colleagues to re-invent the functionality and IDE of Powerbuilder, including its datawindow and foundation classes. (No more new development in Powerbuilder!)
When we brought Powerbuilder in-house at version 5, it had a thesaurus and dictionary; i.e., online user manual with a complete command reference; active, easily searched forums; and local training. I’m not sure anyone is developing this sort of rigorous documentation for open source products. Sybase pays technical writers to develop this boring documentation, and you pretty much get what you pay for…
Language is more than just a vocabulary, it has a grammar and lexical rules for organization (punctuation) and error checking. Simplifying a language to just vocabulary misses one of the big points – you want to be able to retrieve the business logic you’ve stored in the mess at some future point (whether for maintenance or simply to explain how the business works – when it runs automatically, you can bet people don’t really know).
So, while a rich vocabulary may be a plus, I dare say a simpler grammar, and a very simple set of lexical rules are a plus, too.
More to the point, though, use a language (and set of tools) that fits the problem. Trying to use english to explain math doesn’t work, just as using English to explain Chinese words is mostly only useful for Chinese as a second language folks. Trying to do everything with one tool doesn’t work either.
Oh, and when SOA (or whatever’s in vogue at the moment) means I’ll get budget, then I’ll really be excited.
Cheers,
Andrew
Programmer productivity is a ‘Management Problem’ in ‘managing’ to motivate programmers to learn all of the language in which they are programming, not just find some basic commands and try to use them for every problem. Too many are too content with an intermediate school vocabulary rather than becoming proficient with college level erudition. Basic literacy in an advanced language is possibly worse than outstanding competence in a rudimentary language.
While the tools have vastly improved, we have had the ability to extend the vocabulary for as long as I’ve been programming (since 1977). I believe that a large part of the reason that we have not seen a comparable improvement in programmer productivity is that too few people are allowed to invest the time it takes to create a good dictionary, or to spend sufficient time studying those that exist.
To their credit, Microsoft did an outstanding job with the dictionary for their .NET Framework. By and large, it is well organized and documented, and most of the definitions include decent examples, as you might find in the Oxford English Dictionary.
The Microsoft .NET Framework is easy to extend. If you are writing in C#, it is relatively easy to create the dictionary entries as you go, but that can take as much time, or more, than it does to write the implementing code.
Unfortunately, I suspect that far more working business programmers use VB.NET than C#, and the documentation facilities that are built into that language are not nearly as easy to use.
Regardless of your choice of language, the key point is that good documentation takes time, and most working programmers don’t have the luxury. Never mind that, if the documentation were written first, as it should be, many design errors would surface earlier in the development process, when they are much cheaper to correct.
I agree with Andrew that it is more than the vocabulary that determines the productivity of a language. RPG had additional vocabulary and syntax added to it to make it easier for Cobol programmers. The functionality of these Cobol like parts already existed within the language and were much more efficient to implement through the native design. Basically the programmer could turn on a flag in RPG or code a dozen lines to produce the same outcome, two minutes vs twenty. The additionaly vocabulary made for a less productive language if the programmer actually understood RPG. On the other hand, Cobol programmers using RPG without actually learning RPG were made productive by the extra vocabulary.
If you include libraries of routines that programmers must invest the time to learn that they exist as vocabulary… then its the vocabulary that sets languages apart. However, my experience is that programming languages are like tools, each is exceptional at doing the thing that they were meant to do. I have yet to find a language that let you manipulate mixed record types like COBOL did, similar to your SAS example with its capacity to address the problem at hand. Good coders over time build their own libraries of routines that extend their tool of choice, making them more efficient. The problems occur when you put a good programmer in an environment where the only tool you let them use is a hammer when they really need to use a screwdriver. Sadly, this is where many computer shops of today are or are going… “We only use C++ here, its our company standard.” I know this to be true since one of my tasks as a manager to make hiring and staff replacement easier is to do that very thing.