A Systems Analyst's thoughts on science, technology, programming, business, and occasionally politics.

Designing software

September 10, 2008 at 3:04 pm | In Business, Technology | No Comments
by Chris Davenport

My own experience has been that one should shoot for simplicity, treat the business rules differently than design rules, and don’t put your data in your program. I prefer a toolbox approach, when you take it to the multiple subsystem level.

More interestingly… Let’s design “Hello World”. Standard thing to toss out to a starting programmer.

#include <stdio.h>

int main(int argc, char* const argv[])
{
    printf("Hello World!\n");
    return 0;
}

Pretty simple. But in the software world, things change. All the time. Our helloWorld isn’t multilingual. It can’t say “Hello World+dog”. There’s at least one bug in there too. Don’t try to have it say “Hello 95%[World]“.

You could go crazy with it.. add a flag on a command line argument so that it can say “hello world” and “hello world+dog”. Implement unicode routines, hit up a translation site, and hope you don’t get a bad translation. You can get clever with it and make it read the string from an external file, so you don’t have to recompile when the requirement changes for the 100th time.

If you make it sufficiently flexible and abstract, you’ll probably end up reimplementing the TYPE, ECHO, CAT old DOS/Gnu commands.

Which brings up an interesting point. We’re training programmers to use code to solve problems. Even really trivially simple ones.

What makes CAT or TYPE better than HelloWorld? Why are we not teaching programmers that anything you hardcode like that could end up changing?

That doesn’t mean we should design HelloWorld to be much more complicated, but recognizing that there are nearly equivalent complexity implementations that are more flexible in the ways that may change seems like a good idea.

I bet there’s some statistical analysis that can be made.. relating to the odds and difficulty of changing things.. We don’t really expect it to stop printing to the screen, so there’s no reason to design it so that it can edit wikipedia or recognize kittens in a photograph.

Theoretically we’re trying to minimize the lifetime of work that the program requires.

No Comments yet »

RSS feed for comments on this post. TrackBack URI

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>