There is no conflict between speed and quality! That was the header for lesson one of your relearning program. You want to improve software development productivity in yourself, your team or your organization? Then follow me along and debunk a few myths.
Speed versus Quality
Myth: Any project is a trade-off between speed and quality.
Truth: There is no conflict between speed and quality in software development productivity!
When quality is high, it is easier to build.
High quality enables high-speed. This is the insight behind many popular agile practices such as test driven development (TDD), continuous integration and DevOps. It’s when you lose focus on quality that technical debt starts to build up. Pretty soon all your budget goes to maintenance and nothing is left for investments. You need to keep your system (landscape) in a state where you can actually change or improve something.Want to learn more about quality and how to achieve it? I really recommend that you read the World Quality Report.
Skill versus Quantity
Myth: Software developers are just “resources” and can be replaced at will.
Truth: There are vast differences between developers when it comes to software development productivity!
There are individual differences between developers. Let’s say that an average developer has a productivity of 1. A poor programmer might have a productivity of 0 or even -1. That means that a crap developer can actually cancel an average developer. A super star developer on the other hand might have a productivity of 10 or even 30. Such an individual developer can replace several teams of developers. So yes, it does matter to have the right people.
It takes time to build a high performance team. Unless you specifically focus on building transactional memory in the team, that improvement alone can take up to year before it happens spontaneously. People are not potted plants to be moved around by gardenarial fiat but well rooted trees. Their roots are hurt when they move and they leave a hole behind.
Agile versus Waterfall
Myth: Other industries successfully use Waterfall and so should we.
Truth: A lot has happened since the 1950ies and not even the construction industry is waterfall any more.
There is a fundamental distinction between mass manufacturing (replication) on one hand and industries with more uncertainty and design work required such as software development or even the construction industry. But wait, you say, the construction industry is the poster child for the waterfall approach – isn’t it? Starting with the architect then moving on to engineering, construction and finally use. Sure, that was the situation in the 1950ies when almost all construction was greenfield. It’s not like that any more. Construction is now about refurbishing, renovating and rebuilding of existing properties – and no one knows what lies inside a wall or under a floor. The construction industry is moving towards a more agile approach.
Sure, agile does have some prerequisites to work properly but those are not solved by ignoring them. It’s quite clear that if you aren’t already agile, going there is the most important step towards improving your productivity and reducing your problems.
Cloud versus on-premise
Myth: Cloud is just servers in the cloud, it cannot improve our productivity.
Truth: Cloud is one of the strongest accelerators for software developement productivity.
Even if you just think of cloud as a server rental facility (IaaS or IaaS+) that in itself has distinct advantages for software development productivity. The ability to quickly, in a matter of seconds, bring up a whole new environment enables powerful productivity boosters like continuous integration, continuous deployment and even DevOps. But cloud today is so much more than just infrastructure. Today, it is only a matter of hours between you finalizing the design for your product until you can set up the whole supply chain and start selling the first gadgets through your online store. All because of Manufacturing-as-a-Service, Logistics-as-a-Service and even eCommerce-as-a-Service. The same is true not just for physical products but also for software development. A point we proved quite nicely in a project with PostNord.
Software development productivity video
If you don’t treat your people right, they will back off.
That’s what Joakim Lindbom says in the video and so the conclusion of all this is perhaps that you should learn from successful open source projects. Those projects just die if they are not “managed” properly.