Renaissance

Extracts from Steve magurie’s Writing Solid Code.

• You don not save time by fixing bugs late in the product cycle. In fact you lose time because it is often harder to fix bugs in the code you wrote a year ago than in the code you wrote days ago.
• Fixing bugs “as you go” provide damage control because the earlier you learn of your mistakes, the less likely you are to repeat the mistakes
• Bugs are form of negative feedback that keeps tast but sloppy programmers in check.If you do not allow programmers to work on new feature untill they have fixed all their bugs, you prevent sloppy programmers from spreading half implemented features throughout the product. They are busy fixing bugs, if you allow programmers to ignore their bugs, you loose that regulation
• By keeping the bug count near zero, you have a much easier time predicting when you will finish the product. Instead of trying to guess how long it will take to finish how long it will take to finish the features. Even better you are often in a position to drop the unfinished feature and ship what you have.

Leadership roles by Dr.Meredith Belbin

1. Driver : Controls team direction at detailed, tactical level. Defines things, steers and shapes group discussion and activities.
2. Coordinator  : Controls team direction at the highest strategic level. Moves the problem solving forward by recognizing strengths and weakness by making the best use of human and other resources
3. Originator : Provides leadership in ideas, innovating and inventing ideas and strategies, especially on major issues
4. Monitor : Analyze problems from a practical point of view and evaluates ideas and suggestions so that the team can make balanced decision
5. Implementer :  Converts concepts and plans into work procedure and carries out group plans efficiently as agreed.
6. Supporter : Builds on team member strengths and underpins their shortcomings. Provides emotional leadership and fosters team spirit. Improves communications among team members
7. Investigator : Explores and reports on ideas, developments and resources outside the group. Creats external contacts that may be useful to the group
8. Finisher : Ensures that all necessary work is completed in all details. Seeks work that needs greater than average attention to detail and maintains the groups focus and sense of urgency

Classic mistakes that one should avoid while developing a product.

1. Requirements gold plating.
   One should not have more requirements than needed. Right from the beginning of the project emphasis is laid on performance and it is stated as a requirement this leads to unnecessary delay in software schedule. Users tend to be less interested in complex feature than marketing and developers are, and complex feature add disproportionately to development schedule.
2. Feature creep
   In general projects experience 25% change in requirements over its life time. Such changes produce at least 25% addition to the schedule. This is assuming that you are not following the gold plating at requirements phase.
3. Developer gold plating
   Generally developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or create their own implementation of a slick feature that they stumbled upon. The efforts required to design, implement, test, document and support features that are not required lengthens the schedule.
4. Push me – pull me negotiation
   The bizarre negotiation ploy occurs when a manager approves a schedule slip on project that is progressing slower than expected and then adds completely new tasks after the schedule change. Then this happens in cyclic fashion
5. Research oriented development
   Seymour Cray, the designer of Cray super computer, says that the does not attempt to exceed engineering limits in more than two areas at a time because the risks of failure are too high. The lesson is having no more than new variable in development of a product.

What can poor team structure do?

The poor team can increase the development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation.

There are three objectives according to Larson and LaFasto (1989) for having a good team structure.

1. Problem resolution
2. Creativity
3. Tactical execution

Problem resolution team focuses on solving a complex, poorly defined problem. The team members need to be trustworthy, intelligent and pragmatic.

Creative team explores possibilities and alternatives. The creative team member need to be self motivated, independent, creative and persistent.

Tactical execution team focuses on carrying out a well defined plan. The team is characterized by having highly focused tasks and clearly defined roles. Success criteria tend to be black and white, so it is easy to tell whether the team succeeds or fails. They also need to have a sense of urgency about the mission, be more interested in action than esoteric intellectualizing and be loyal to the team.

From Steve McConnel’s Rapid Development

Staff selection for team projects (Bohem 1981, Software Engineering Economics)

1. Top talent : Use better and fewer people
2. Job matching : Fit the tasks to the skills and motivation of the people available
3. Carrier progression :
   Help people to self actualize rather than forcing them to work where they have the most experiences or where they are most needed
4. Team balance : Select people who will complement and harmonize with each other
5. Misfit elimination : Eliminate and replace problem team members as quickly as possible

In addition to these Steve McConnel adds people’s design ability, programming ability, programming language experience, machine and environment experience and application area experience.

Some of the classic mistakes in software development

1. Lack of risk management
2. Friction between developer and customer
3. Planning to catch up later
4. Insufficient planning
5. Silver bullet syndrome
6. Short changed design
7. Uncontrolled problem employees
8. Project heroics
9. Adding people to a late project
10. Ineffective project sponsorship
11. Undermined motivation
12. Overly optimistic schedule
13. Short changed quality
14. Weak personnel
15. Unrealistic expectation
16. Code-like-hell programming
17. Overestimated savings
18. Noisy, crowded offices
19. Omitting necessary tasks from estimates
20. Feature creep
21. Inadequate design
22. Lack of user input
23. I was here syndrome
24. Contractor failure
25. Research oriented development
26. Switching tools in middle of the project
27. Wasted time during the fuzzy front end
28. Shot changed upstream activities 

From :
Steve McConnell’s Rapid Development

These are some of the software evils, better be aware of them as they can come and bite at the last moment.

1. Shifting requirements
2. Poor schedule estimation
3. Unreliable contractors
4. Management inexperience
5. Personal problem
6. Bleeding edge technology failure
7. Performance shortfalls