Fact 9: To stay productive, a developer must not switch activities too often.
A developer takes 7 to 15 minutes to become efficient at resolving a complex problem. Switching from one activity to another (phone, email, etc.) interrupts the developer's progress. For instance, a team where the developers answer tech service calls every 20 minutes is catastrophic. One must not allow users to call the developers directly.
Instead, one must set up a tool to gather questions, bugs, nice-to-haves, and requests, so that the developers can concentrate on their jobs. Tons of available tools can gather the demands, including Mantis and Jira.
Remember, a developer is not a tool; a developer is a human being. Why do managers keep asking developers to rememberstoretheir demands? Aren't the managers smart enough to write their needs down?
Fact 10: Defining the architecture is as important as coding.
Coding without architecture is like driving at night without lights. You may arrive at your desired destination, but the journey is dangerous and slow. Architects must review the organization's products often and anticipate problems. Without the architect's input, the complexity of the product grows each time a new functionality is added.
Even when the coding was all right, projects that I know took the fastest path to the result usually went wrong. This is where an architect should have provided an overall view of the product architecture and proposed alternative coding paths.
Fact 11: Developers have different priorities than product owners do.
A developer tends to work on "fun" tasks, while the product owner wants something useful for his or her clients. The development process must lead to a better approach, where the developers find it exciting to work on annoying issues.
From what I've seen, Scrum seems to be a very nice method to use for this. It proposes a process in which the developers commit themselves to delivering results on time, and pride is a strong and powerful motivation! While developers are challenged to deliver on time, managers are challenged to think twice before requesting features that will be of no use. Have a look. Scrum seems really great.
Fact 12: Coding conventions are efficient; they must be imposed.
Coding conventions free developers from needing to understand the form of the code, allowing them to concentrate on the code's core meaning instead. In the teams I've worked in, we ended up setting conventions for the directories where we put the code, for the file names, and for the form of the code itself (the naming of the classes, methods, variables, etc.). Many other conventions can be proposed.
Some SVN add-ins even forbid commits when the code does not follow the conventions. Great!
Nip Efficiency Issues in the Bud
Most development processes and methodologies aim to address efficiency issues. This article pointed out some of the development facts I've observed that are at the heart of these issues. I hope you can learn from my experience, and while no one solution is a silver bullet, I recommend having a close look at Scrum because it enhances the commitment of every actor in the development chain.