Sunday, August 17, 2008

Open source development vs. business development

Over the past eight months at my current job I have had an opportunity to work with various people in designing new programs to fit their business needs. While working on the projects, one aspect has become clear, developing free open source software is vastly different from developing software for your employer.

The writing of the software isn't so different. You still need to plan your software(based on requirements), write it, and then test it. In my experience, many open source projects are planned rather poorly. They are then initially coded up rather quickly to a point of working "well enough". The programs tend to be somewhat tested by the developers but rely heavily on "community testing." This often results in more than a few negative user experiences. Development of many open source programs begin to stagnate after a while and end up in a continuous state of development, never really being done.

In business environments, software development I have found works differently. Planning is done with a "client". Rarely does the client actually know the full requirements of the software they are requesting. I generally try to understand the client's current business process they are trying to enhance/automate etc. While discussing the business process with the client, we try to determine the actual requirements based on the business process. (I have found that the client doesn't always know the complete process or may forget parts. Its good to involve a few people that know and work with the process.) One fact about the software requirements, they will change throughout a project, no matter what.

After the requirements are known, the real work can begin. However unlike most open source software there is a very real and probably very near (closer than you would like) deadline. There is little time to be spent refactoring poor inflexible code. Its very useful to take the time upfront to really think about your approach, you also need to plan for testing. I have found that testing generally takes just about as long as writing the program. This is not necessarily because of a large number of bugs but rather who is testing and how much attention they give to it. I like to involve the client in the testing process as they know the process the best. They are the ones who will be able to spot logic errors in the process. The clients tend to think about the process much more differently than myself as the programmer, what was clear to them may not have been clear to me. Anyhow, testing... allow ample time for it. I often find myself and the client testing right up to the deadline. Even after the deadline problems are often found while the software is being used in a production environment. Testing is very important when your software will have a real impact on businesses and user impressions of that business.

1 comment:

  1. Nice post. I had the same experience with poorly designed open source projects. In some cases people tend to think that if they implement an "of the shelf" component or platform there is no need to designed it till the final detail.

    Regrading software testing, I found it the most challenging effort on the development cycle. You can't really test ALL the business functionality and rarely you really plan enough time for it. I think that long run services like will be a great help.