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 : Page 2

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


advertisement
Fact 4: It takes time for a developer to switch from one project to another.
Often, setting up a development environment for a project is difficult. It may be nearly impossible without very good knowledge of the project. When it takes too much time to set an environment up, developers tend to stay in the same environment for too long. A developer should be able to switch from one project to another without technical difficulties. The "project culture" is difficult enough.

I advocate using project management tools like Apache Maven. A project described in Maven tends to be very easy to set up in Eclipse. For Java projects, just download your code from SVN, type "maven eclipse", refresh, and it works. All your unit tests are ready to run against your code. Whoa! A whole project set up in less than 30 seconds.

For technologies other than Java (Python, C, etc.), Maven with standard plug-ins is not enough.



Fact 5: Bugs increase as the number of developers increases.
Without the proper methodology, the number of bugs tends to grow with the number of developers. So the quality decreases with the complexity of the project. One must work against this tendency with the simple principles of transparency, code reviews, and automated tests.

Transparency ensures that anybody can look at the code and determine who has modified what, when it was modified, and if possible, why it was modified. Transparency puts more pressure for quality on the individuals in a team.

Code reviews enable any developer to discover and prove a bug's existence. It's amazing how powerful they are for improving quality.

Fact 6: Tests have several layers.
Writing good tests is a tough challenge. For example, writing unit tests on existing code is very difficult, and they cannot test everything. Functional (QA) tests are powerful for challenging your application, but they usually run slowly and fail to give enough information about the cause of the problem.

So you must divide and conquer. Running huge tests is useless if the fast ones do not pass. Create test layers from the simplest to the most complex:

  • Level 0: Unit tests on the developer's own environment
  • Level 1: Unit tests on a build server, started on (almost each) commit
  • Level 2.1: Integration tests, where you try to have several modules connected together (You replace the mock objects with the actual modules you created. For instance, you would use an actual XML parser instead of a mock one.)
  • Level 2.2: Integration tests, with access to the system (socket, disk, etc.) (Here you can test the actual access to the system.)
  • Level 3: Functional tests, where you test the visible part of your application (actual functionalities seen by the user) (This layer is certainly not enough.)
  • Level 4: Performance tests
  • Level 5: Customer use (OK, this is not a test layer, but it certainly is a source of surprising new bugs.)

You need to start the more complex tests only if the simple ones pass.

The motto of this methodology is a bug should never appear twice. Therefore, for every bug you find, you should create a test that guarantees that it will never happen again. Sometimes the test is a unit test (which is better), sometimes it is an integration test.

The sooner you get the error, the sooner you correct the issue. So you'd better begin running tests at Level 0 rather than Level 3, and the code quality tends to increase naturally with the number of tests.

Fact 7: You must have a restricted number of languages.
If you choose the best tool for every task, the number of technologies you use tends to grow fast. If you always take the quickest path to the short-term goal, the complexity of the system grows. Therefore, you should sometimes choose not to use the best tool. Using only one or two languages in a team is better than using more, because training people on new technologies costs a lot. For instance, Ruby on Rails certainly is a very productive tool but it's one more language and technology. One should consider the whole cost before deciding to develop that new web site with this technology. This policy certainly does not apply if your main activity is creating web sites, because in that situation Ruby may become your team's main language.

In my opinion, choosing a limited number of programming languages is the way to go. You must also assess the technologies in use in your company. For instance, is it very productive to use four Web services frameworks? One likely is enough.

Fact 8: Tracking change and innovation is necessary but difficult.
It is very easy to miss out on a tool that can save you a lot of effort. If you don't know about it, you can't try it. Tracking changes and innovation in development frameworks and methodologies prevents this. Thanks to this type of tracking, I discovered almost all the tools I now use: Eclipse, Maven, Tomcat, Apache, LDAP, CruiseControl, TestNG, Python, etc. Most of them saved me weeks, if not months of development time.

The difficulty is in choosing the tools (it takes time to choose) and preventing your team from having too many technologies at the same time. Sometimes, it's better to wait a bit to capitalize on one technology before implementing a new one.

Another challenge is choosing the new technologies to evaluate. It's not easy to choose between all the competing frameworks and evaluate only one or two.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap