Downside
Chapters 14 and 15 cover "Negotiating" and "Signing up" respectively. Signing up means commitment to delivery and hence involves integrity in preparing estimates. Joe admits this is one of the most difficult areas in managing projects and, indeed, we found some positions a little hard to take. Of this, Joe observes:[13]
book combined. Software developers and their managers are very uncomfortable with the hard line I take on commitments. They keep trying to explain to me that 'software development is different.'"
Joe then says:
"Well, sorry, folks, but I just don't believe it. Every area of human endeavor has risk and uncertainty. Every project ever undertaken has some new or novel element in it. All projects have schedules that are too short and resources that are inadequate. Just ask your brethren in other domains. You are not that special."
"It's not that I'm unsympathetic, you understand. Software does have some peculiar problems. The most vicious of these is management's misconception that large changes can be made at the last minute through the magic of changing just one line of code. This is not reality, but fantasy. More likely, when a problem is found, it will take major rework, just like in any other area where architecture governs the result."
This is all very true. Yet like research and development projects, software development is different. The results of the effort are, for the most part, intellectual rather than tangible. That leads to two major differences:
- Tangible products are more easily visualized, making the product easier to plan and execute
- Tangible products, as for example in construction, generally require a trade skill rather than an intellectual skill and such people respond to a different type of management.
In fact, Joe acknowledges as much in Part 5 of his book because he introduces it by observing:[14]
"The theme of this section is that software people think differently. Some of their ideas are speculative, maybe a little off the beaten track. It's helpful to gain the insight of seeing some of the various ways in which they look at problems."
All of which explains, albeit very briefly, why project managers "brought up" in one domain frequently have difficulty in switching and accommodating to the other.
Joe discusses appropriate pay for software professionals in Chapter 16 and, as you might have guessed, presents an interesting model of compensation. This model relates job difficulty with skill level.[15] However, it postulates a range somewhere between an individual's anxiety due to the difficulty being beyond his or her skill level on the one hand and boredom due to the job being too easy on the other. Somewhere in the middle is an area of satisfaction where there is a feeling of wellbeing that results in a high level of achievement.
Joe goes on to expand on this model and how it might be applied to software development work. In reading this section we were left with a number of unanswered issues. For example:
- The concept assumes that the organization is big enough to have a whole bucket-full of jobs of all kinds covering a range of difficulty from which to choose from and that can be dispensed to the working people to fill their working day regardless of the sequence and needs of project activities
- It also assumes that compensation is in the hands of the technology leaders who understand degree-of-job-difficulty, and not in the hands of professional "human resources" managers who know little about the challenges of software development
- And, when it comes down to actual dollar compensation figures, how do you compare the value of different work anyway?
13. Ibid, p177
14. Ibid, p195
15. Ibid, p184
|
What
We Liked - in Parts 3 & 4
