Complex tools, simple developers: A match made in hell

The developer shortage is coinciding with newer, more complicated tools that most workers can't really use

It is a weird American custom in which asking speakers difficult questions is considered “giving them a hard time,” and I am apparently famous for doing so. At nearly every meetup for event-based, nonblocking, asynchronous programming toolkits such as Node.js and Akka, I ask one question that goes something like, “Have you ever used this on a large team with differing skill levels and gotten the less skilled developers to use it correctly?”

I’ve never got a satisfying “yes I have and here is how I did it” kind of answer. That is a real problem.

There are two concurrent movements going on in our industry:

One is an attempt to cheapen labor by going to “low-cost countries” and using various schemes to skirt temporary-worker wage regulations.

The other is an attempt to have fewer developers do more with less work. This gets labeled “developer productivity,” but the term is often marketing nonsense meant to hype a programming language. However, real technical advances have taken place to allow greater scalability through better use of resources in parallel at the hardware (my smartphone now has as many cores as my two-year-old laptop).

Although both trends are ultimately about reducing costs, they're bolstered by a true shortage of good developers. Our culture and thus our universities are failing the task of encouraging and making technology jobs attractive to enough young minds, even as older programmers are discouraged to remain in the business.

Worse, we were told we wouldn’t be able to get tech jobs because “the dot-com bubble is over” and all the jobs would go to “low-cost countries” anyhow. Although it didn't quite work this way, it created a meaningful dip in the number of people with enough experience to run a development project.

Although you can find experienced and skilled people in “low-cost countries,” they are not the people you get when you pay the bottom dollar to a firm that specializes in charging you the bottom dollar for development work. Hiring domestic graduates — though we face a shortage, they do exist — isn't a panacea because they don’t magically come out fully skilled and ready to roll. Many come out not knowing what a mutex is, for example.

All this means that on any large effort you have a team of a few really skilled developers and a lot of not-very-skilled developers. How are you going to use functional programming and do a whole event-driven nonblocking highly parallel architecture?

I’ll be honest: This challenge is why when developing software, I still mostly use Java and generally avoid being too “cute” unless it saves me enough time.

The only constructive answer I’ve come up with — which doesn’t work very well with distributed teams — is to pair more experienced developers with no more than three less-skilled developers. This doesn’t scale to a very large project, but it helps the motivated, less-skilled developers become more skilled faster.

Source: http://www.infoworld.com