Login | Register   
LinkedIn
Google+
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

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


advertisement
hy are so many articles and books written about development methodologies? I believe it's because improving the efficiency of a development team is a never-ending battle. Technology keeps changing and teams must adapt or die, but adapting is time-consuming. Customers need fast development cycles with higher quality. With the advent of offshore outsourcing, developers now come from different countries, in different time zones, with different cultures. And as everybody does, developers tend to concentrate on tasks that are interesting and usually not the most productive.

In this complex development world, I have encountered very interesting issues as a team manager and developer. This article presents a formalized list of the most troublesome facts of development I've come across, and it offers some suggestions for handling them. (The original version of this listing was posted on my blog.)

Fact 1: Maintenance cost is the biggest enemy of efficiency.
Maintenance cost pressure naturally leads development teams to low efficiency. Maintenance costs tend to be more or less proportional to the number of lines in your code, especially when it is not properly tested. As the number of lines increases, the team discovers that the number of bugs tends to grow for internal reasons (bugs) or external ones (not really bugs but need to be corrected anyway).



An external reason may be a change in the way the code is used. For instance, your code works perfectly with JRE 1.4, but JRE 1.5 is here and the show must go on. Your code must run with it, and if it does not, you have a bug from your customer's point of view.

Because the perfect code does not exist, you must think differently. You must take maintenance into account even before you code. Think about how to test before thinking about how to code. Moreover, you must determine specifically how to have your servers test your code for you—a test that cannot be automated is only half a test. Then the team will be able to test its own code effortlessly in any new environment and extend the tests quickly and efficiently.

You must find a way to enable every line of code to be automatically (and fully) tested. This is not just an issue of unit testing, because unit tests cannot test everything. In fact, tests are more efficient when they are separated into layers (more on the layers later).

Fact 2: Developers don't like to test, and they don't test their code the way they should.
Code that works in one place is supposed to work every place. This is absolute nonsense in real life, but developers actually live in a virtual world where everything is supposed to follow norms without encountering bugs. For instance, a J2EE application that works in JBoss is supposed to work seamlessly in WebSphere as well. (LOL) Therefore, developers need to test their code on all targeted platforms with minimum effort. Otherwise, the tests just won't be run. If they are, they won't be run properly. The way a developer generally works is code, compile, and forget.

I believe you need a framework to run the tests on every platform and store the results in a database. To sum up the process: write tests in any language, automatically test on every targeted platform, and store the results. Then you can review the history of the test results on any platform for every version of the code.

I know some tools espouse those features. For example, the BuildBot open source project seems to be working on it, at least in the near future.

Fact 3: When a bug is discovered, it takes much more time to isolate it than to correct it.
You must react quickly when a developer modifies code and checks it into the code repository. Test the committed code promptly, so that if a test fails, the developer remembers what he or she just did and where the bug originated.

If the developer doesn't remember, he or she can look at the code history and see the differences between the two versions. The bug can be isolated in the code that changed. The developer won't have to spend hours to find the bug.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap