Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Top 12 Productivity Killers in Your Development Methodology : Page 3

Find out what the 12 most troublesome facts of development are, and learn how they can affect efficiency.


advertisement
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 remember—store—their 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.



Laurent Ploix is in charge of code quality and efficiency at Sungard Front Arena, a Sweden-based provider of integrated cross-asset, end-to-end solutions. He has been developing front office and back office financial applications since 1996.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap