Developing A Web Application With Open Source Code

By Shourov Bhattacharya, Symmetri
5th February 2007

During my formative years as a web developer, I lived in the world according to Microsoft. I cut code in ASP and then ASP.NET using Visual Basic and then VB.NET and C#; I used the Microsoft Visual Studio IDEs; and I developed databases and stored procedures using various versions of SQL Server. I was part of large corporate teams where I had little input into decisions about tools and technology. I worked with what I was given - and had no chance to explore the alternatives.

Now I have the freedom to make my own decisions about how I work. But with that freedom comes the obligation to use the technology that is best suited to the job. It is a choice that I make for each project based on the client’s preferences, technical constraints and an understanding of technology. Sometimes that means using ASP.NET and SQL Server, or another proprietary platform such as Java or Cold Fusion.

But more and more that choice is leading to open source platforms, tools and code.

A recent project involved developing a company CRM system on the LAMP (Linux-Apache-MySQL-PHP) stack and using an open source codebase called vTiger as a starting point. Like all good projects, the entire experience taught me something about both software and people - including myself.

Hell is other people’s code

A good software developer knows how to work with other people’s code. After all, almost any software development is done by multiple people who must read and understand each other’s work, often distributed over both space and time. Reading other people’s code and dealing with their differences is an essential skill for a developer.

But working with open source code has its own challenges.

Open source code tends to be "messier" than what you’d be likely to get in a corporate-controlled software product. Because the developer base is so diverse and disconnected, open source code has large variations in style. Where a corporate team may have to adhere to standards over time, open source developers follow their own trajectories when it comes to how the write their code. And not all open source developers are good developers.

In blunt terms, that means learning to deal with code that is just plain bad.

The vtiger codebase, for example, has portions that are almost unreadable. Variables defined and used across multiple files, local variables that clash with globals, functions nested within others for no reason, a lack of naming consistency even within the same function- it’s got it all. For someone more used to the rigid quality control of a commercial code-shop, that can be quite a shock.

And after the shock comes frustration - a feeling of "how the heck am I supposed to work with this!".

Put prejudices aside

The way to deal with that feeling is firstly to recognise that not all bad code is really all that bad. Much of what a developer regards as "bad" or "wrong" is simply prejudice - a conviction that one’s own coding preferences are superior to others.

For example, would you use SQL statements directly in code? Would you put global variables in capitals or with a prefix? Would you use functions in code to output HTML? A good web developer will have answers to these questions and reasons for their way of doing things. But when developing with open source code, there are times when preferences have to be put aside in the interests of getting the job done.

And often one’s preferences aren’t that great anyway. There was a time when I would never create a variable without prefixing for type - a hangover from Visual Basic days. But working with first C# and then PHP has forced me to be more intelligent about scoping and naming variables. There might be good reasons to still use the prefix, but now I do for the right reasons - not simply out of force of habit.

Still, the code in vTiger modules was sometimes so bad that it made me angry. But it also forced to think about why I was angry. That kind of reflection is a good thing.

Create islands of excellence

Even when you are dealing with genuinely bad code, eventually you just have to wade in and start work. Whatever other developers may have done, when you write code your own standards should remain unaffacted. There is a temptation to take short cuts when you can see that your inherited code is already full of them. But your code is in your hands. Good, correct code always enhances the product, even if it is just an island of excellence surrounded by mess.