The major problems of [software development] are not so much technological as sociological in nature.
The idea that most of the problems in software development come from the people, and particularly mistakes made in organising the people, is obvious to those of us with experience. None of the failed or failing software that I’ve taken over were trying to break new ground in algorithms, practises, data, or hardware. They were just another run-of-the-mill application that happened to be scuttled by bad team dynamics.
The technical aspects of software development have made huge strides in the past 30 years. Test automation, test driven design, design patterns, code smells, static code analysis, continuous integration, and continuous delivery have all made fundamental improvements to software development during my career.
We’re making slower progress on management. Scrum’s wide-spread success has changed the way that we manage software development. Some very clever psychology is built into Scrum. Scrum is specifically designed to build teams out of individuals, and to build trust between the teams and their stakeholders. Scrum gets rid of anti-patterns like fake deadlines, and validates everyone’s desire for process improvement.
Unfortunately we’re still making a lot of the same mistakes with people. More often than not successful teams are broken up after successful delivery. “Everyone is replaceable” is the battle cry of human resources, not “everyone is unique”. And far too often we respond to suggestions for improvements with witch-hunts.
If you haven’t read Peopleware, you should. Expect to rearrange responsibilities to match shifts in abilities and interests, not to replace one person with another. Learn from both the cultural and the process causes of your failures. And prioritise a healthy culture: In the long term you can’t hope to develop software competitively without a workplace culture that values every individual.
RSS - Posts
Be the first to comment.