Software Economics

Jason Gorman describes (in a very nice manner) how software courses are lowering the bar. It’s up to us to keep the bar higher.

I agree completely. Yet what happens with scrum certification in the last years, has started long before. We’d like to think of software as a craft and development as a skill. If that was true, there could be a big change in software quality, cost of maintenance will drop, and customers around the world will be dancing and singing hallelujah.

Software, like anything, succumbs to supply and demand. The bad news is that most developers are average. As with every large population, we can rate them all on a bell curve. With age and experience there’s a shift to the right (more good developers), but against that, new inexperienced developers come in (more bad developers), and some leave the trade altogether (all kinds). So most of developers remain “average”, economically speaking.

Companies don’t want software to be developed by average developers. They would like them to be excellent. But those excellent guys cost a lot, because they are in short supply, and the recruiting takes ages.

So the next best thing: Get average developers and get them to a better level. There’s a risk that when they become better, they’ll leave for a better pay somewhere else. That’s economy for you. But usually companies understand that the risk is much lower than the risk of going out of business because the developers remain average. So how do they do it?

The traditional way is training. They bring in a great trainer, pay him a lot, and let him do his thing. And then they expect some ROI. Turns out it’s a recipe for disaster.

The problem is that a few days courses really can’t raise the level of developers. But that’s not all: In fact, there’s a bigger problem. Organizations can’t really calculate the ROI, since they can’t evaluate the current level of software skills, can’t measure the training result, and how it translates to actual business. That’s because the people who organize these courses don’t understand the (low) value of courses. Or software altogether. The disaster comes when expectations crash, usually on the heads of the developers.

Ah, but where ignorance is abound, there’s money to be made. There are many who offer courses from HTML to CSM (or the “learn 3 languages in 1 day” Jason described), because there are many companies, who don’t understand software, but are willing to invest in what they think will give them a competitive edge. Cue the crashing sounds.

Software takes a long time to learn to do right. At least a few years. Good software people know that. They can actually raise the bar for recruiting and training other developers. They can train new and average developers to become better.

But mostly, it doesn’t even make a dent in the whole software economy. Most developers are average, and raising the bar to their level just means more average developers. It’s just mathematics.

Of course the developers reading this blog are not only above-average – they are also smarter, taller and more beautiful. To you I say- raise the bar. Get as much as you can from the software economy.

Just as long as you remember there’s a big system in play. Set your expectations realistically.

The numbers are against us.

4 comments on “Software Economics”

  1. Thomas Weller Reply

    Hi Gil,

    my experience from the past few years is that it’s even worse: It is hard to even establish a common understanding of ‘good software’ among a team of developers – not to speak of establishing agreed goals and/or quality measurements.
    My impression is that there is not really a common concept of software quality and its possible consequences to a project’s ROI among developers – wherever they may reside on the bell curve. Sure, everybody agrees that something has to be done, but it’s hard to find two people who mean the same thing when they say ‘something’. Also, the educational background among various developers in a team sometimes is very diverse, so it’s almost impossible to reach common ground – for sure this is impossible to reach within a timeframe of 2-3 days or even 2 weeks.

    So yes, there constantly will be a high demand of software training in the near future, but I’m not very positive that this will in consequence lead to better software. Not until newbie developers will be teached a commonly agreed and scientifically backed concept of ‘software quality’ as natural part of their education…

    — Thomas

  2. Gil Zilberfeld Reply

    Thomas,

    Thanks for the comment!
    High demand leads to low quality because companies need to lower the bar and settle for less.

    What can drive quality up is customer expectations. The need to survive in a competing market may drive companies to counter the cost and short supply.

  3. Lior Friedman Reply

    Gil,

    While the message is good.
    two questions need to be asked:
    1) Where do you think Scrum (and Agile) would be today without the infamous Scrum Certification?

    2) On average, how would you rate the amount of business value an average programmer today can produce, in comparison to an average programmer 20-30 years ago?

  4. allan kelly Reply

    What was it Demming said, “98% of performance is the system” ?
    – you can improve the performance of developers (even “average” ones) but doing so may well mean changing the system they work in.

    Software developers are their own worst enemy a lot of the time. Most of them are reluctant to ask for training courses or go on them. How can you expect the right courses to be chosen when those on the receiving end opt out of discussion?

    And have you ever tried to convince a programmer to have some one-on-one coaching? – I can convince managers quite easily but programmers… they have this “self sufficiency” or “can’t be shown not to know something” attitude so every time a manager says to me “I understand, lets see if the guys want it” I know it won’t happen.

    Training courses can be a good start but if they aren’t followed up – changes in process, practice, follow up coaching, etc. etc – then they are simply an event.

    The ironic thing is: one-on-one coaching is actually cheaper than training courses overall but few people see that.
    The cost of training isn’t the cost of the trainer, its the lost time of the people on the course. Put 10 programmers on a 2 day course and the cost of the trainer is little next to the cost of your people for 20 days (a month!).

    Instead pay the trainer for 10 days of coaching (1 per developer of pair programming with the coach) and while their bill will be higher the company won’t lose so much productivity. Indeed what they do loose will quickly be paid back in the days after the pairing.

    That’s the true economics here.

Leave a Reply

%d bloggers like this: