Tuesday, December 7, 2010

The Software Developement Life Cycle

"Designing the database? What's the big deal, it's all about writing half a dozen CREATE TABLE queries, right?"

I was working on my semester project where we had to build a complete database application in Java. I had just started my work, and was bending my head looking at my basic abstract notion of the application, trying to decide what tables I need and what data do I put on them. This was when a friend called in, wanting to know my progress. I told him that I've just started with it and was designing the database - and he asked me this.

I was not shocked in any sense, because my friend represented 99 percent of India's undergraduate population, who believes programming means the code - bringing up your IDE or whatever editor and punching in lines and lines of code - that says it all about programming. 'Seriously, what else is there to it,' are you thinking too?

A lot, a hell lot, in fact - perhaps you remember from your Object Oriented Programming or Software Design, this rhetoric phrase - "actual coding contributes to only 30% to the total software development life cycle" - there are equally important phases like analysis, design and modeling. Despite this, when we are given a software product, the first thing we do is jump on our keyboards and start punching in hard code. The methodologies stay in the books, either being too good for us to try out, or just being mundane and irrational, a mere waste of time. So are they, really?

I wanted to find out. With a semester project that need to be completed in the next three days, this wasn't the best time to experiment, but I took that chance. I took out my notebook and a pen, conjured up the my database with the required data, normalized them, refined them; and in an hour, I was left with six tables in Boyce-Codd Normal Form. Ah, quite a feat, I thought, considering this was my first real attempt a practical database design problem.

With my tables in my hand, I contemplated if the hour spend was really worthy enough. I was slightly surprised that it was -- during my design process, the database underwent 3 major revisions, and the tables ended up quite different from what I originally had in mind. If I had attempted coding the tables downright, this would have meant having to rewrite the code entirely a couple of times - that would already take an hour and then leave me in frustration that I'll need to spend the next hour doing something else.

With my six little tables, I sat in to code them up in SQL. After 15 minutes, the database was done - the magic is, no single line of code, no single query was written, which was surprising again. I was depending upon the mySQL Workbench, which did the query-generation for me - all I had to do was create a schemata, arrange my table within it using the well designed GUI, and sync it in to the database - done, and zero coding thus far.

With the backend in place, the next task was designing the GUI front-end for my application. In this situation, however, it was not necessary to actually draw out the windows and buttons on paper before I implement them - since I was using my NetBeans IDE for this purpose, I was "drawing the windows anyway", and there was enough room for errors and improvisation.

Designing the GUI only held more surprises - with the entire GUI frontend ready, complete with the event-handling, I still hadn't written a single line of code. NetBeans automated it all. From laying out my components on the screen, to setting up events like "click this, and that window appears" or, "tick this box and that text-field is active" - everything could be handled using just the GUI, and no coding.

So this was all the software modules, frameworks, and component-based development jargon all about, I realized. And as I leaned back in my chair starting to take a break with "The Social Network", this amazing thought stuck me - for the first time in my life as an engineering graduate, I was applying something I was learning in my books. Absurd call, that's what I'm always meant to do - but this was indeed an idea worth cherishing for an engineering graduate in India.