Why 12 months is too long and procedural code is just wrong

Writing internet software is always a roller coaster ride. I often look at 'desktop' application developers with envy. They have the luxury of a relatively stable operating system which can go many years without any major developments which could make their code redundant. They also can write for a specific operating system, whether it's Windows, OS X or Linux, they know they only have to target one specific operating system. I'm sure that application developers view internet developers with envy, but you'll have to visit their blogs for that insight.

Internet scripters don't have those luxuries. We have to write portable code that has to run on a handful of different operating systems that all bring their own development problems. (Side note: Who at Microsoft thought that using the escape character, the backslash, as a path separator was a good idea? I'd like to meet him and see if I can get some money back on therapy required after running the stripslashes mine field). We also have to use a series of ever-changing scripting tools such as PHP or perl tied into databases with frequent and code-breaking changes. This creates a very unstable development environment.

This brings us to the title of this prose: twelve months developing a product for the internet is too long. Many things change on a daily basis and you can never assume that the development platform you're using to write your code is still going to be valid by the time you've finished the initial code base or rewrite. I learned this the hard way.

Learning the hard way

In a previous life, I developed and maintained a perl project. This project got to the point where it was obvious that a rewrite was required. The architecture was struggling under the weight of bug fixes, hacked in features and code limitations. I had taken a basic and badly designed code base as far as I could. I was conversant in perl and didn't really want to switch to another language. This was back in those dark days when perl 6 was lauded as "right around the corner" and PHP had triumphantly released PHP 3 and development of PHP 4 started. PHP 3 was a weak language with too many restrictions and work arounds needed to manage a project the size of the one I was managing. It wasn't a hard decision to continue writing perl. Perl 6 was on the horizon so it made sense to ditch procedural code and work entirely in OOP (object orientated programming). I created a lavish frame work with a modules and class system. I figured that when perl 6 was picked up and used on our customers' servers I could simply rewrite these modules independently without affecting the framework. I also wrote an intricate database abstraction class which could load sub-classes to process a query set I developed which meant that if a database engine changed, I could rewrite the sub-class without needing to touch a single other file.

The theory was sound, no doubt about it. Unfortunately this took nearly 18 months to complete. I went over deadline by a spectacular 6 months and was forced into releasing a product which I knew wasn't complete or anywhere near bug free. To complete the project properly could have taken well over two years. We upset a lot of our customers with repeatedly missed deadlines and while we were rewriting our code, the web hosting industry moved from perl to PHP 4 and perl 6 became more of a pipe dream than a reality. After 18 months of hard development all I was left with was a brilliant theory, outdated code and unhappy customers.

Lesson learned

This mistake was still very raw when I began the foundations of a new product. It was obvious that it couldn't take too long to release the first version and the experience helped me form a development roadmap. This time around, I'd develop the framework with the same ideals but introduce a smaller feature set. These features could be introduced over time with quicker version releases.

OOP was an obvious choice for this new project. A lighter, more manageable database abstraction engine was created to handle changes to relational database engines and a class structure was employed to cover the basics such as emailing, printing output, template handling, etc. Modules were introduced to handle different information requests. All of these objects can quickly be rewritten without changing any other code.

Procedural code is simply too hard to manage when a project reaches a certain size. The need to bug fix, maintain and introduce new features creates a mess of code which runs out of control. The architecture is hardcoded into each file which makes the system inflexible. A rewrite is inevitable and just a matter of time and it'll take a good deal longer to rewrite procedural code, which is time badly invested.

I recently released a major version increment which introduced many new features and a fresh interface. I'm still using the framework I devised nearly three years ago. Nearly every module and class has undergone some surgery to introduce new features and to maintain the project but I was able to approach each module as an independent part of the greater program. I was able to turn around a major release in a little over 6 months and without needing to rewrite every line of code. I couldn't do this with the procedural code I had previously developed.

The moral of the story

The moral of the story is very simple. Don't ever bite off more than you can chew and the first release doesn't have to be the last release. Plan your development wisely and aim to release frequent updates to achieve the feature set you originally had in mind. Use OOP where you can and always keep in mind that the code you're writing will need to be maintained and eventually rewritten. Invest your time well and you'll never have to apologise for missing your own deadline by six months.

Oh, and if you're writing an operating system, never use the backslash character for anything important. It's for escaping characters and nothing else.