Software is too expensive to build cheaply….

I saw a presentation today from BEA on the Weblogic Workshop. The tool was pretty nice, but it crystallised an idea that has been kicking around in my head for a while now. Quite simply, I’m not sure these sort of tools are good for development use.

The idea behind the tool is that for every decent software developer out there, there are at least 10, maybe a lot more, who aren’t very good. These “developers”, often stereotyped as VBA programmers, are people who can do a decent drag-and-drop interface, but can’t really build anything complex, either due to lack of native ability or due to lack of training. This was especially true during the dotcom-craze, when millions of people worldwide tried to get into IT when they really didn’t have a natural aptitude for it.

(To any VB programmers reading this, I won’t apologise. VB has an immense number of followers, many of whom can’t code their way out of a wet paper bag. OTH, there are also some very good VB programmers; no stereotype is absolute. There are also a lot of crap Java programmers)

The problem is that there aren’t enough good developers out there. The BEA guy gave numbers of about 2 million decent developers vs 15-20 million “HTML hackers”, world-wide. I’m not about to question the numbers; certainly, the ratio is either right or optimistic.

It’s a well known principle of software development that good developers are considerably more productive than the average, and one of the reasons is that the average is pulled down a lot by the bottom end. The bottom end developers really aren’t capable of anything more complex than doing form-based, VB-style of development. In fact, many of them do VB-style of development. However, with MS shifting VB over to VB.NET, many of these people aren’t going to be able to make the jump. So BEA came out with the WebLogic Workshop, in the hope of being able to steal some developer marketshare.

All of this is well and good, and to be honest, the Workshop would allow an inexperienced or mediocre programmer to pull together an app quickly. However, these tools don’t remove the fundamental complexity of the problems; they only hide it. And that’s where the problem occurs.

Take a typical team: 4 to 5 junior programmers, and one senior lead programmer (who is probably with less than 10 years experience, maybe even less than five). The 4-5 junior people are going to be cranking out code, and the senior person is going to spend his or her time reviewing a lot of it to make sure that it’s okay and no design flaws have crept in. Now, these 4-5 junior people are keeping the senior person very busy, and the senior developer still needs to crank out the “sensitive” code; the stuff that has to work. Now double the junior developers productivity (or even just increase it by 20%). What happens?

In an ideal world, the team starts becoming more productive. However, the world isn’t ideal. In fact, what really happens is that the senior developer can’t keep up anymore. The junior staff won’t have their work reviewed, or the sensitive stuff slips. Defects start slipping through, hopefully to be caught by a testing team. Most of these defects will be to do with special cases, or with scalability/reliability constraints. In the end, an apparently functional application is built and delivered, but underneath, it’s very brittle (just like a lot of VB apps, by coincidence). Quite possibly, the application spends a lot of time in the test cycles, eating up all of those productivity gains. And the junior staff won’t be able to fix the bugs, because they won’t understand the technology underneath the covers.

The other problem here is that a certain percentage of those junior staff can make the transition to journeyman status; not all, but a reasonable amount. But they won’t be able to accomplish it if the real complexity is hidden. They’ll never come to grips with the concepts behind the code that make the transition possible. Potential cut short. 😦

These tools have a strong place. But I wouldn’t want to use them on my mission-critical apps, and not on many of my non-mission-critical apps. If it’s a small app, and it will only take a few days, then knock it up with these tools; small investment, small risk. Anything bigger, think twice before doing it like this.

Now, I’m not old enough to remember the debates when 3GL languages were introduced. However, I suspect that the current point-and-click style of tools are at a similar state to the early 3GLs. The first ones introduced more problems than they solved. But they won through in the end, as problems became too big to deal with in assembly code and the 3GLs became more sophisticated. The true crossover point came when it was possible to write a compiler for a language in itself (you can even do this in Java, including writing a JVM in Java (admittedly, it would have to run inside of a JVM, but you could do it)). When these point-and-click tools become sophisticated enough to do that, they’ll have made it.

(A secondary problem is that graphical/visual interfaces aren’t necessarily any better at organising complexity than normal OO code… But that’s another issue, for another day).

That’s all for now. Thanks for reading.