The depreciating dollar, sub-prime crisis and a few other factors have forced companies to look at other ways to improve the margins and where-ever that is not possible, at least retain the existing margins. Increasing productivity is one area where managers are told to focus on. As with all cases, there are and will be people who claim quick cures for the productivity problem that we face. The low lying fruits have all been picked up and the others take more time and effort, to deliver results. The bad news is that that there are no quick cures. There are no silver bullets. And the good news is that the ‘Productivity Problem’ has been thought of and discussed in many software management books, articles and papers. Peopleware – Productive Projects and Teams – by Tom De Marco and Timothy Lister , has covered this issue a long time ago, to be more precise, in 1987, when most of us were in school [atleast i was :-)].
I have given below an extract from the book that rebuts some of the myths around increasing software management productivity. As always, all emphases are mine.
We are all under a lot of pressure to improve productivity. The problem is no longer susceptible to easy solutions, because all the easy solutions were thought of and applied long ago. Yet some organizations are doing better than others. We are convinced that those who do better are not using any particularly advanced technology. Their better performance can be explained entirely by their more effective ways of handling people, modifying the work place and corporate culture.
The false hopes engendered by easy technological non-solutions are like those sirens that tempted poor Odysseus. Each one reaches out to you with her own beguiling message, an attractive fallacy that leads nowhere. As long as you believe them, you are going to be reluctant to do hard work necessary to build a healthy corporate culture.
We have identified seven from the field that we know best, Software Development, and we present them below along with our response.
#1 There is some trick that you have missed that could send productivity soaring: You are simply not dumb enough to have missed something so fundamental. You are continually investigating new approaches and trying out the ones that make the most sense. None of the measures you’ve taken or are likely to take can actually make productivity soar. What they do, though, is to keep everybody healthy: People like to keep their minds engaged, to learn, and to improve. The line that there is something out there that you have missed is a pure fear tactic, employed by those with a vested interest in selling it.
#2 Other managers are getting productivity gains of one hundred percent or two hundred percent or more!: Forget it. The typical magical tool that’s touted to you is focused on the coding and testing part of the life cycle. But even if coding and testing went away entirely, you couldn’t expect a gain of one hundred percent. There is still all the analysis, negotiation, specification, training, acceptance testing, conversion and cut over to be done.
#3 Technology is moving so swiftly that you are being passed by: Yes, Technology is moving swiftly, but most of what you are doing is not truly high-tech work. While machines have changed enormously, the business of software development is still static. We still spend most of our time working on requirements and specification, the low-tech part of our work. Productivity within the software industry has improved by 3-5 % a year, only marginally better than the steel or automobile industry.
#4 Changing Languages will give you huge gains. Languages are important because they affect the way you think about the problem, but again, they can have impact only on the implementation part of the project.
#5 Because of the backlog, you need to double productivity immediately. The much talked about software backlog is a myth. We all know that projects cost a lot more at the end that what we expected them to cost at the beginning. So the cost of a system that didn’t get built this year (because we didn’t have the capacity for it) is optimistically assumed to be half of what it would actually cost to build, or even less.
#6 You automate everything else: isn’t it about time you automated away your software development staff? This is another variation of high-tech illusion: the belief that software developers do easily automatable work. Their principal work is ‘human communication’ to organize the users’ expressions into formal procedure. This work will be necessary no matter how we change the life cycle. And it is not likely to be automated.
#7 Your people will work better if you put them under lot of pressure: They won’t—they’ll enjoy it less
Couldn't believe that what he wrote 20 years back were sound applicable!
ReplyDeleteLanguages can have impact only on the implementation part is incorrect. Language bring in certain benefits/constraints to the architecture design and some times even impact the requirement considerations.
I couldn't understand why the SW backlog (ie, the work that was deferred for a later phase) was considered a myth by him. Doesn't it happen all the time?
Siva, TDM says that language change brings in huge gains is a myth. The gains a new language brings in arent so enormous that they bring you manifold improvement in productivity. The point is that none of the new technologies will bring in a great improvement in productivity for us to call these as a silver bullet.
ReplyDeleteMany application development projects still and will always depend on good requirement capturing and project management skills to see them through. the problem is that most of the time, people tend to forget it and claim that a new technology will bring enormous benefits and will help you finish projects faster. Peopleware claims that a new language brings in a 5 % productivity increase ( you have to consider the learning curve and all the associated stuff with learning new things).
Software Backlog: The statement because of back log you have to double the productivity is a myth makes the following point. The mythical back log doesnt have a reason to exist and the doubling the productivity is a myth that will not happen. the authors point is this. projects because of poor effort estimation cost double the estimated cost, at the end.So the cost of a system that didnt get built this year( because we didnt have the capacity fot it) is optimistically assumed to be half of what it would actually cost to build, or even less. The typical project that is stuck in the back log is there because it doesnt have a valid business case.
I hope i have answered both your queries to your satisfaction.
thanks.