BrainDump
  Home arrow BrainDump arrow Page 2 - Lessons Learned Managing Software Deve...
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Actuate Whitepapers 
VeriSign Whitepapers 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
IBM developerWorks
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
BRAINDUMP

Lessons Learned Managing Software Development in Startups
By: Rangachari Anand
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 34
    2004-08-10

    Table of Contents:
  • Lessons Learned Managing Software Development in Startups
  • Source Code Management
  • Tracking Bugs
  • Release Management and Lessons Learned

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    Lessons Learned Managing Software Development in Startups - Source Code Management


    (Page 2 of 4 )

    In the first few weeks of my company's existence, I was given the task of setting up a source code management system. After evaluating several alternatives, I decided to go with Razor from Visible systems. The main reasons were the modest cost per seat and the relatively good integration of bug tracking with code management. A trial version was available and we tried it out for a few weeks. The results of the trial were encouraging but ultimately Razor did not go over well with our developers when put into production. The main problems at that time (mid 2000) were:

    • The CLI client tool was hard to use (compared to CVS). Since a number of our users had worked with CVS, this was an important objection.

    • The Linux GUI client was a little clunky to use.

    • It turned out that the client and server had to be mutually reachable over the network. From what I could make out, this was necessary to allow the GUI to change file status in real time. Since our developers sometimes needed to access the server through a NAT (Network Address Translation) gateway, this turned out to be a big problem.

    • One more administration annoyance was that the Razor server was locked to a particular machine. Since our IT infrastructure was far from stable, this caused a lot of problems since each transfer of the license had to be approved by Visible.

    Due to these problems, and also general resistance from the developers, we switched to using CVS for source code management. Since we were still in the experimental phase, there was no urgency in setting up a bug tracking system (which we lost by abandoning Razor).

    Our CVS server is configured so that every CVS commit resulted in an email containing details of the commit being sent to all developers. Developers generally save commit emails in a folder in their mail reader and use the built-in search facility as a sort of a database to search for commit data.

    In addition to each developer's private store of commit messages, we also use a tool called Bonsai that saves CVS commit messages in a relational database. A convenient web UI is available that allows one to perform complex queries against this database. Bonsai is invaluable at release time and when trying to determine whether a bug has actually been fixed.

    There are many problems with CVS and these have been adequately described elsewhere, but the main issue that one needs to be aware of is a cultural one. CVS is great as long as its used in the way that its supposed to be used. In general CVS works best where the philosophy of development is along the lines of "it's better to ask for permission than to get permission". CVS is not a tool that works well with a "command and control" approach to managing development.  Despite this caveat, there will be times when it is necessary to lock a branch --  for example, when finalizing a release. This kind of locking can be added by using server side wrapper scripts although we have not done this so far.

    The other big problem with CVS in the context of commercial development is the lack of any means to group commits together (i.e. changesets). When finalizing a release, for example, it's important for the release manager to know exactly which bugs have been fixed and which new features have added. This problem can be overcome by having developers include a reference to a bug or feature in the commit comments. If this convention is followed diligently, it is possible to track down all commits for a particular bug or feature with the help of Bonsai. However, mistakes often happen -- usually at the worst possible time. Developers may neglect to include a bug reference or may reference the wrong ones.

    If we were starting today, and decided to use open source tools,  we would definitely use a better tool such as subversion. We have considered switching to subversion right away but have delayed a decision since the advantages do not appear to be compelling for now.

    More BrainDump Articles
    More By Rangachari Anand


       · i was looking for a article about pm and you told me exactly what I wanted to know....
       · To me this article seems like an advertisement. I'm sorry but there's no *useful*...
       · I think that this was an article telling of his experiences and a lot of information...
     

       

    BRAINDUMP ARTICLES

    - More Amazing Things to Do With Pipelines
    - Pipelines Can Do Amazing Things
    - Better Command Execution with bash
    - Executing Commands with bash
    - Outsourcing: the Hoopla, the Reality
    - MySQL Plays in the Sun
    - All About SQL Functions
    - SQL: Functioning in the Real World
    - More Advanced SQL Statements
    - Beginning SQL the SEQUEL: Working with Advan...
    - Beginning SQL
    - A Look at the VI Editor
    - A Quick Tour of Boo
    - Book Review: Open Source Licensing
    - PGP and GPG: Email for the Practical Parano...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 4 hosted by Hostway