Blame those lazy software engineers

The quantum leap that mobile phone software has made during the past years proves it again: people are lazy. And that definitely holds true for good software engineers.

(photo by Alessio Re)

Let me take you back to the year 2000. Everyone was buying mobile phones and the market kept showing double digit growth numbers. We saw small scale innovation here and there: the first micro browsers, phone contact backup applications, ring tone management, etc. But they didn't influence the numbers by much. Things like packaging, shell design and product bundling had much more influence on the final sales numbers.

This lack of success caused software departments to go into hibernation mode: keep the status quo, copy the features the competitor releases and don't waste energy in trying to create software that will not make a difference anyway. The odd developer or team that tries to create something new is soon demotivated and indulges in laziness and reports non existing progress on a project that is likely to be killed soon (read my hidden 12 year old testimonial on this).

The truth is that software engineers are not lazy. They love to dive into new projects and they work like crazy to prove they can get the job done. The problem lies in the nature of software engineering:

• it takes almost no effort to duplicate or build upon what has been done before
• it takes an enormous effort to create something genuine and new

The difference between both classes of software development can only be seen by a competent manager. Since most projects are managed by numbers and not by content, serious software innovations stand no chance in a non-disruptive business environment.

To put it simply: We need something like the iPhone to happen upon us to raise the bar for the whole industry. All of a sudden, the development teams at Samsung, Nokia and Sony-Ericsson create wonderful features and slick UI's. This is because the disruptive change in the market forces technology management to stop focus on short term objectives and give some breathing room for more substantial innovation.
Methodologies like Scrum ensure software teams are productive, but this comes at the cost of innovation. When software engineers have to "hide" their creative side-projects, innovation can never foster. People go into "stay below the radar" mode and clueless project managers have no idea why projects aren't being delivered. (see my Scrum++ article)

If you don't understand the (creative) process of software engineering, don't try to manage it. Empower your team and let them handle the planning. You might be surprised with the results.