Building software or growing it?

For the past week I’ve been working on my first multi-person, long term software project. As part of my summer research project we’re building an urban planning system which automatically builds sample cities from a set of design conditions. I’ve been working with two other people and my professor, and though it isn’t a large scale project like writing an operating system, it’s still quite challenging. One of the major challenges that I’ve come to face is that it’s a very hard to stick to any designs that may have been made before actual writing of code. Furthermore, in a research project such as the one I’m working on, the problems aren’t well known and we’re discovering them as we go along. This results in the problem that I’m continually rewriting parts of my code and adding parts as I go along.
In class we were always taught to plan out our programs in a engineering fashion, and then implement. I’ve tried to follow this plan-then-implement methodology, but I’ve to improvise quite a lot. So I’ve been wondering, what’s the best way to make large pieces of software: grow them or build them? Building software is what I’ve been taught in class: where we make a  plan and then follow it. Now anyone who has written a sizeable amount of code will now that it’s impossible to plan for all eventualities. That’s what debugging is all about: dealing with things that you didn’t plan for. However debugging deals with errors, not with the basic structure of the architecture. I’ve previously advocated carefully planning out algorithms before implementing, and i still to that. But when it comes to actually building large software systems, it’s important not to try to plan everything out. I’ve come to realize that it’s best to combine a moderate amount of planning with a technique of organically growing your software.
What do I mean by growing? It’s simple, start with something small, that you know works (and that you’ve tested thoroughly) and keep adding on to that. You keep adding functionality one bit at a time, getting closer to what you finally need. This method has a two fold benefit, firstly it makes sure that you have a working program before you starting adding more functionality. That lets you rollback to a working program whenever things get out of control. Secondly, it leaves you free to add functionality and deal with complications without having to worry about fitting things into a preconceived plan.
A well conceived plan is good and essential to a successful software project, however it’s good to leave room for the eventualities that will inevitably occur, Growing software and building things on top of an already working base is a way that allows creation of software in a structured manner that leaves room for dealing eventualities.

Advertisements

Published by

Shrutarshi Basu

Programmer, writer and engineer, currently working out of Cornell University in Ithaca, New York.

One thought on “Building software or growing it?”

  1. And the software should of course stay whole
    after its growth 🙂

    I think this is probably one reason why most
    software which is extendable is usually
    more popular. Not only is this is a nice
    way to start off on open-ended projects, but
    also it allows other people to add on to
    the work once it has finished.

    I once read a review about Emacs which said
    that emacs was literally a living system in
    that one could change the functionality ‘live’,
    and since it was so modular, it was easy to
    extend (no wonder some people call it an OS!!)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s