I-Am-Bot Code, technology and life

31Jan/104

Of application rewrites

What will you do if you write a shitty application? And what will you do when you find that you have written a shitty application? I've been haunted by these questions for the past two days, and yes, I'm guilty as charged. Before someone thinks I sound like someone who knows programming, let me clarify - NO I DON'T. And that is exactly the reason for this post.

The application that I worked on wasn't something big and impossible. It was a simple school management system, written in PHP/MySQL with a liberal dose of javascript thrown in. Unfortunately, it just didn't make it to the servers, and I abandoned it about 6 months ago. Much has changed in that time, and thankfully. I now really understand the need to follow Software Engineering processes, the most important being Design. So why did my team, and I choose to ignore something we've actually studied in college? Were we dumb enough to think that we wouldn't be needing it? Probably. Were we not actually able to understand why we will need it? Possibly. The only reason that readily comes to my mind was because we never knew that we will actually need it.

Software Engineering courses in Indian colleges are often the most boring, monotonous and brain-dead courses among the lot. Throw in a thick rimmed, thick skulled man in his 40's who has never worked on a real application all his life, to teach it and you have a 2012 waiting to happen. And it often does. We students cram the Pressman's book a day before the exam, answer standard questions about SDLC, Testing, importance of SE, and get away with it. And that is that. We are never taught first hand on why we need it, how we should use it, how badly it will affect the software if you don't follow certain principles, or why learn SE at all! Those are left to the student to discover after a few years, just like I have.

So what exactly was my application? It was

  • Very simple and modular
  • Web based for universal access
  • Not that huge or complex (Our team of 4 completed it in 3 working months)
  • Architecturally simple

Then why did we screw it up? We did everything that we could think of. We first gathered requirements, refined them, thought we did some design, then went on with the coding. Too bad we thought we designed it! We did not. Looking back, I feel really stupid about some of the decisions we took based on our understanding of the system. We knew we had to design it properly, but we didn't take it seriously as we didn't really know its consequences. I am no programmer, and if I feel my app is shitty, it really has to be!

Where did I go wrong?

  • No framework
  • No separating of logic from presentation. It was all embedded in a single file in true PHP fashion
  • No proper design of the entire system. No HLD/DLD
  • No glue. The code looks like disjoint pieces of a puzzle

What I did right?

  • Probably the architecture
  • With PHP/MySQL
  • Revision Control which was never used seriously

So the question beacons - When does one decide to rewrite/redesign an application? I need not have decided on redoing the whole thing. I could have as well patched it up, and sold it as many still do. It would still work, can be understood by almost any developer, and I wouldn't have to waste time and money on a rewrite. Decorate shit and it will still be shit. If one doesn't learn from mistakes at the first instance, he/she probably never will. So I finally did what I should have done in the first place:

  • Designed a breakdown of the entire system into modules and the coupling between them
  • Decided against going for a fully blown framework like Symfony as that will add unnecessary complication to a simple application, but rather write my own simple framework to separate code from design
  • Chose mysqli as the database driver and developed a simple wrapper around it
  • Added a logging system which was entirely missing
  • Work on a custom design from scratch, which will also work on portable devices
  • Write a generic framework for the reporting module with custom graphs and charts rather redo the entire code
  • And many many more...

The point I'm trying to make is, no one is perfect to start with. As a programmer, I was happy with my code 6 months back. Now I despise it. It is not something I can work on anymore. So rather than choosing to ignore the mistakes, swallow your ego, acknowledge the mistakes and redo it. Yes it is hard, painful, time consuming and costly. But software is a continuous process and the continuity is there for us to learn, undo and redo things the right way. I bet I will find blunders again after 6 months, but they will not be as bad as those I've found now. Maybe then, I can afford to patch things up, and be on my way.

For now, back to Software engineering : a practitioner's approach by Pressman

P.S: This post is more of a reminder to myself than to others.

About Srinath

No description. Please complete your profile.
Comments (4) Trackbacks (0)
  1. may be coincidence, but recently i was thinking about it too.. didnt understand the need for SE principles at that time.

  2. Thankz Srinath,You really tought me some Basics of SE,which I was supposed to learn at college,but I have`t.

  3. I don’t know if you remember this but once we had an argument on “Anyone can code!!”. The point I was trying to accentuate there was how well you design & modularize the code.. Still I will stick with what I said :)
    Anyone can code but.. only a few can code sensibly and the latter one is all that matters ;)

  4. @Sandy, coding sensibly comes with practice. It all depends on how open you are to learning. For example, I’m marginally better at S/W design than I was when I started with my project. Not everyone is born a genius, but you can get there if you work hard and are open to learning from your mistakes


Leave a comment


No trackbacks yet.