Software project management is a major aspect of software development. People generally only think about it when changes to it are being considered. Most of the time it’s just part of life. It determines your role in a software group, how to interact with others in your group and is the central function determining whether efforts are successes or failures.
Some form of project management is required for all software projects – otherwise they are considered out-of-control amateur efforts. Sadly, this is a nearly universal bad idea – project management has proven to be a disaster for software development.
A core trouble is that the ideas of software project management are based on inappropriate physical metaphors such as architecting and building a house.
https://www.blackliszt.com/2018/12/software-planning-is-impossible.html
I wrote software for a number of years. I got the stuff done people wanted quickly. Then I joined a company that was infected by experienced professional managers and got project management force-fed to me.
https://www.blackliszt.com/2012/10/software-project-management-book.html
I studied more and found there were many thousands of books on the subject!
I learned that there were intense disputes in the industry about the subject, particularly concerning the widely-mocked “waterfall” method that was giving way to supposedly better Agile methods.
https://www.blackliszt.com/2013/03/software-comparing-waterfall-and-agile.html
Regardless of the religious sect of project management to which you belong, the key factor is how much time you spend writing code versus doing anything but writing code. With rare exceptions, spending more time writing code rather than just about anything else leads to better productivity.
https://www.blackliszt.com/2012/09/software-productivity-the-abp-factor.html
Why is project management so bad? Don’t you want to know how long something will take and what it will cost before you dive in? Of course you do! That’s why it refuses to die. The absolute core issue is that all forms of project management optimize for predictability, starting of course with estimation.
https://www.blackliszt.com/2012/06/the-nightmare-of-software-estimation.html
When you dig in, it turns out that all those estimates and dates lead to dysfunction. Someone who says they’ll run a mile in 20 minutes and makes 19 is praised, while someone who hopes to do it in 10 minutes but makes 11 is a failure.
https://www.blackliszt.com/2010/10/software-project-management-dates-are-evil.html
The whole notion of releases needs to change.
In spite of all the fervor about Agile etc., the fact is that nearly all software projects are way too expensive and slow and have crappy results.
https://www.blackliszt.com/2021/02/why-cant-big-companies-build-or-even-buy-sofware-that-works.html
https://www.blackliszt.com/2014/04/delivering-software-is-a-nightmare.html
The solution is widely proven by small groups that really need to win instead of getting praise from experienced managers. They use grow-the-baby techniques with post-hoc design and wartime methods.
https://www.blackliszt.com/2011/06/software-how-to-move-quickly-while-not-breaking-anything.html
https://www.blackliszt.com/2022/09/better-software-and-happier-customers-with-post-hoc-design.html
https://www.blackliszt.com/2013/05/wartime-software-optimizing-for-speed.html
The book I wrote has lots of explanation about the issues.
https://www.blackliszt.com/2012/10/software-project-management-book.html
Comments