Book: “Dynamics of Software Development”

 “Dynamics of Software Development” by Jim McCarthy

Although this book published almost 20 years ago, it has some timeless rules that are still applicable today. Here are a few lines from the book:

• “If the leader can then resonate with the team’s complex emotional state–identify with it, articulate it, and give the whole constellation of feeling and thought a visible, concrete reality in his or her own personal voice or gesture–the boundaries among the individual team members and between the team members and the leader will collapse.”
• “The truth is hard to take, challenges your character, but whether the truth is offered by someone else or you discover it independently, you have to listen to it eventually… Not only must you listen to the truth, but you must broadcast it to the rest of the team. And the medium for transmitting truth among humans, like it or not, is emotion.”
• “not to slow the pace of change, or to create more stability; but to get good at change, at managing technology in motion.”
• “you are not going to get away with many more than two developers for every one QA person”
• “If a balanced group of people are mutually accountable for all aspects of design, development, debugging, QA, shipping, and so on, they will devise ways to share critical observations with one another. Because they are accountable, if they perceive it, they own it. They must pass the perception to the rest of the team.”
• “leadership in software development require a high degree of sensitivity to the human nature of the enterprise, an awareness of the underlying drives and emotions that determine the team’s behavior.”
• “if you are having a hard time understanding something about the team, you can look to the software. If the team and the software both tell you the same thing, you can act on it with some degree of confidence. Conversely, if the software hasn’t reach the desired state, the way to fix it is to analyze the genesis of the problem in the team.”
• “Freedom is the cornerstone of empowerment, freedom to develop and apply judgement, freedom to think and say what needs thinking and saying, freedom to take risks without extraneously punitive consequences.”
• “Empowerment is the result of teaching and learning, not neglect and anarchy.”
• “invest significantly in paradigm-shifting features… Once you make a breakthrough in the paradigm arena, your competitor will be forced back to the drawing board, even if he or she is momentarily ahead in the feature shoot-out.”
• “Shipping is the hardest thing to do. If you’re better at shipping than y our competitor, you’re likely to be better than y our competitor at virtually everything. Timely, frequent shipping is the manifestation of well-being on a software development team.”
• “Teaching becomes the primary function of leaders and managers.”
• “in a product that had unity, each element would be essential to the value of the whole and all essential elements would be there… since everything the customer needed would be there, the customer wouldn’t be tempted to go beyond the present experience, and that since nothing would be there that wasn’t required, the customer’s absorption into the world of the product wouldn’t be disturbed.”
• “It should be a fundamental dogma that the person who has to do the work should predict the amount of time it will take.” “The ultimate act of disempowerment is to take away the responsibility for the schedule from those who must live by it.”
• “You need to build schedule meticulously from the bottom up. Each person who has a task to do must own the design and the execution of the task and must be held accountable for its timely achievement. Accountability is the twin of empowerment. The two together can create a reasonable software development plan.”
• “As a development manager, you’re working with only three things: resource (people and money), features (the product and its quality), and the schedule.” “When considering the possible solution to a schedule shortfall, keep in mind there are only four possible: add time, subtract feature, add resources, or do some combination of the three.”
• “when something is unknown, the best policy is to state that simple fact, even if the unknown is not knowing when the software will slip.”
• “The goal on a software development project is not to have the correct plan in advance but to make the right decision every day as things that were unknown become known.”
• Team interdependence as a motivational factor to deliver software on-time: “The goal is to create a network of self-motivated individual commitments.”
• “If you have an ’empowered development team’ deliverables are negotiated among developers, writers, program managers, and testers. ‘Management’ has virtually nothing to say about deliverables.”
• “Slipping isn’t the problem. Being surprised by slipping is the problem. A slip doesn’t say that the product is too hard to develop. Being surprised by a slip says that the organization is broken. People aren’t thinking. People aren’t talking to each other. People aren’t aware of the global situation.”
• “A good general rule is that you don’t reset the schedule until the total extent of the slip is known for each component, the cause of the slip are understood, and remedies are in place.”
• “The biggest mistake I see managers make as they hire people for software development team is that they overvalue a particular technical skill… Much more important than a particular technical skill is a history of relevant skills accumulation.”

Advertisement