About Me

My Photo
I am a Software Architect and Developer based in Bangalore, India. I have experience in building (scalable) applications using Java, JSP, JSF, JBoss Drools, Spring Framework, Hibernate, Ajax, JavaScript, MySQL, NoSQL (HBase, Project Voldemort). I am also a fan of Ruby on Rails, and have done some experimental work with it.

Thursday, December 21, 2006

Spaghetti

I guess every one knows what a Spaghetti code is - a code which is hard to understand and maintain, a code which everyone is so scared to touch that bug fixes are always quick and dirty, and which makes code further spaghettier.

I wonder has anyone thought about spagetti products. It may not consist of Spaghetti code, but uses myriad of technologies, frameworks, and solves variety of domain problems that its very difficult to add a new component in it. Hence, it becomes difficult to adding a new component in a consistent way, due to lack of consistent architecture and implementation.

Let me give an example. One of our clients had a product which was written in using Windows 16-bit API and was run on Windows 3.1/NT. The application was well accepted by customers, and they wanted more and more features. The new features and applications were developed using MFC. Then came the era of Web based applications, and the initial version of web based components were built using ASP, COM & IIS. But some team members were equally fascinated with Java and applets, so some web GUI was developed using Java Swing. A portion of the product was developed by college grads as their project, and that was again Java swing based application.

Given a product which uses a range of technologies and has evolved over period of time, the team responsible for adding a new component has a wide variety of technological choices to make. And sometimes, team pick the technology which they are comfortable with.

And, we will have something, what I would like to call, a Spaghetti product.

Add to this, the changes in team over period of time, transitioning of product from one team to another team, outsourcing to partners, the product also runs the risk of developing spaghetti code. Over a period of time, it not only becomes difficult to maintain the product, but it also becomes equally difficult to enhance the product features or to add new components.

Such products are typically a good candidate for re-architecture and re-design.

Re-architecture and re-design do not guarantee that new product wont evolve to become spaghetti product over a period of time. It just adds a new life to the product.

It seems to me that every code ultimately becomes spaghetti code, and every product becomes spaghetti product.

I also wonder whether Frameworks too will become spaghetti framework one day. Take Spring for example. It started as IoC container and light weight alternative to EJBs, but it has now lot of extensions such as Web Flow, Acegi security, and others which make it more spaghettier. Even though I am yet to read the whole of Spring 2.0 documentation, I sometimes feel that there is just too much being offered in one place, and probably its the pressure to keep adding value to the framework which forces teams to extend it release after release. Extensions may make sense in some cases, and in some cases it may be just an overkill and something which is added to level with competing frameworks.

Sometimes, the technological advancements also forces extension. For instance, addition of annotations in Java 5.0 has pretty much lead to a wave of augmenting XML based configuration with annotation based configuration. And, now, everyone has 2 ways doing same thing, and not only that number of choices you have to make has just gone up by 1.

Spaghetti seems inevitable at every aspect of software development. Isn't it?

Posted this article on TSS too. Here is the link
(http://www.theserverside.com/discussions/thread.tss?thread_id=43601)