Not the Pink version, the Monty Python version.
Every few years somebody winds up the "PowerBuilder is dead" argument, and every few years we beat it down again. This time it's Mary Brandel of ComputerWorld and her list of the "top 10 dead (or dying) computer skills". PowerBuilder made #7 on the list, which also included:
1. Cobol (that's the way she spelled it)
2. Non-relational databases
3. Non-IP networks
4. cc:Mail
5. Cold Fusion
6. C Programming
7. PowerBuilder
8. Certified Netware Engineers
9. PC Network Administrators
10. OS/2
The article claims that it is the result of talking to "several industry stalwarts". Folks actually sited include Stewart Padveen of AdPickles, Heikki Topi of Bentley College, David Foote of Foote Partners LLC, Nate Viall of Nate Viall & Associates and David Hayes of HireMinds LLC. I'd never heard of Stewart Padveen prior to this, and I wasn't exactly knocked out by his company's web site ("earn money every time you send an email"). Heikki Topi might qualify as some sort of industry expert; Bentley is recognized as one of the top IT colleges in the country. However -- unless things have changed significantly since I left graduate school -- you didn't consult with colleges and universities to determine what the trends were. They were generally 5 to 10 years behind the times, and often taught languages that stressed concepts (SmallTalk for object-oriented programming) rather than the tools that were actually used the in the workplace. Certainly Ruby on Rails is a pretty hot topic nowadays, but I couldn't find a class that Bentley offered for it. Foote Partners is a IT salary research firm; I can't speak to David Foote's qualifications one way or the other.
As for Nate Viall and David Hayes, they operate recruiting firms. I spend 10 years working for the consulting arm of a recruiting firm. One of the things I learned there is that recruiting firms operate best in a sweet spot where there is a balance between the supply and demand for a particular skill. Too much supply, and the companies looking for that skill stop using recruiters. They don't need them because they don't have an issue finding qualified applicants on their own. Too much demand, and the candidates stop going through recruiting firms because they have no difficulty finding companies looking for help on their own. As a result, when recruiters tell us how much activity they are seeing for a particular skill, all they are telling us is where in the supply versus demand balance we are at. The company where I'm working at now has hired 5 new PowerBuilder developers in the last 7 months (and we're looking for more incidentally, send me a note if you're interested). We are working with a recruiting firm, but not one of those new developers were hired as a result of the recruiting firms efforts. If you asked the recruiting firm, they'd probably tell you there isn't much activity for PowerBuilder. As a company looking for people, I can tell you that there's much more demand than supply.
Along those same lines, I did a quick search on Dice.com for "magazine authors" and "PowerBuilder". I got 344 results for "PowerBuilder", but only 11 for "magazine author". Based on those results, it would appear that Mary Brandel's own occupation is in a lot more trouble than PowerBuilder development! Of course, I don't pretend that the methodology used provides an accurate description of the landscape. But it's important to remember (and seems to have been overlooked in the article) that lack of data in a particular area of analysis often cannot be extrapolated out to prove a point. Incidentally, if you are interested in being a magazine author, the PowerBuilder Developer's Journal is looking for such. But we aren't using Dice.com to search for them. Send myself or Nancy Valentine a note if you're interested in writing for PBDJ.
Let's look specifically at the items included on the list. 4 of them are programming languages, and for programming languages I prefer to rely on the TIOBE Index for an evaluation of what is "hot" and what is "not". To be honest, PowerBuilder has never faired well on that index since I've been watching it, but let's look at the others. C comes in at the #2 slot, COBOL (which is actually spelling in all uppercase by the way) came in this month at #20, and Cold Fusion at #32. Not too bad for "dead or dying" languages, and a particularly strong showing for C. Why C is on Mary's list is hard to explain. Its used extensively in embedded systems and for developing operating systems. I just downloaded the source code for Java's JDK 1.4.2 and lo and behold it contains C code. COBOL is still used extensively for business applications. Even ComputerWorld itself printed an article only a few months ago noting that. MySpace was originally written in Cold Fusion, although it's since been largely ported to C#. Ben Forte of Cold Fusion fame has his own response to the article, though he does appear to believe that PowerBuilder should be on the list. What is perhaps most ironic is that the Bentley website (remember that one of the "industry stalwarts" quoted is from Bentley) is written in Cold Fusion.
cc:Mail I can understand, except that it was end-of-lifed in 2001, so it's hardly news. Given that Novell is actively attempting to move NetWare customers to their version of Linux, it's not surprising to see it here too. And IBM stopped selling OS/2 in 2005, although it is still used extensively to power ATM machines. So those three make sense on the list, but they also aren't shockers to anyone.
PC Network Administrators is a bit hard to explain here too. Certainly there has been a recent emphasis on server consolidation. But until PC networks go away (which I don't see happening anytime soon), there will always be a market for network administrators. I'm not going to take on non-IP networks or non-relational databases, simply because I don't know what Mary's definition of those terms is. When she discusses "non-IP networks" she talks primarily about SNA, but I would think that IPX/SPX and NetBEUI would fall into that category. When she discusses "non-relational databases", she talks primarily about mainframe hierarchical databases, but I would think flat file databases, object databases and post-relational databases would fit that category as well. I'd also have some limitations on what I considered a "relational" database: Access wouldn't make it -- despite what Microsoft claims -- and it seems to have significant usage.
That leaves PowerBuilder. As I've indicated earlier, the problem I see isn't with people having the skill and not being able to be employed with it (which the article would imply). It's that there aren't enough people out there that know how to use it. Certainly articles like Mary's don't help in that regard. Frankly, it's still the most productive tool I know of for doing client development on the Windows platform. Sure I could do the same thing in C#, but it would take me several times longer to do it. But a lot of new developers entering the market don't know that, and articles like Mary's aren't going to help them to learn it. Such articles then might eventually become self-fulfilling prophecies: she'll convince enough people that the product is already dead that it will eventually die because nobody wants to use what everyone knows is a "dead" product.
However, there are signs that the demand for PowerBuilder developers, while not increasing significantly, is also not decreasing. The percentage of listings for PowerBuilder developers from sites like indeed.com or itjobswatch.co.uk show little change in PowerBuilder job listings as a percentage of total listings since 2004/2005.
So, "I feel fine." But folks like Mary still try to do somebody a favor and whack PowerBuilder over the head. We need to see some changes so that we don't get mistaken for the dead. Those might include .Net features, such as those that are being introduced in PowerBuilder 11. But we also need some marketing. Since we apparently can't wait for Sybase to do that, perhaps we need the viral kind. The Ruby on Rails fans came up with some of their own, including this one.
No comments:
Post a Comment