Monday, September 10, 2007

From one to many

Last weekend I (again) discovered what every programmer / architect knows anyway:
The step from doing something on ONE item to doing it on MANY items is the hardest.
And there's an add-on:
Moving from ONE to TWO (in the above sense) is more complex than from TWO to MANY (unlimited).
The reason for the latter is that (to me) "2" is still not as generic as "n", or as I like to put it:
2 is just a special case of 1
quite often if you (in code) have to do something specifically twice, you don't use any loop or iteration construct, you just do it twice.

only if you have to push beyond 2 people start to use collections and iterations.
for (Object o: somecollection)

just for 2 objects, no-one bothers to create a collection, they just instantiate two objects.

At least thats what I usually do - and I know others as well.

But - as I said - I experienced the "from 1 to n" problem last weekend - let me elaborate:

In our neighborhood we have a great service that delivers a box of vegetables right to our home.
There's also a website, where you can check this weeks contents of the box.

Unfortunately, though, the site does not offer an RSS feed.
No problem, I just create(d) my own, with a simple job, that runs daily:
  1. connect to the site
  2. scrape the contents of the site
  3. re-format them
  4. and put them into a (static) RSS file, hosted on my homepage.
Put that RSS URL into iGoogle and have the contents right there in my personal google portal.


Just 2 weeks ago, we decided to have 2 boxes (one with vegetables only, one with vegetables and fruit) on alternating weeks. So I had to re-write my little thing to handle two different "boxes" instead of just one.
(Frankly, I just went for the n-solution, not the 2)

I more or less had to totally re-design the whole hack... About the only thing that remained quite stable was the core RSS handling (through Rome) and the scraping/parsing of the HTML (using HTMLparser).
What I had earlier looked more like a classic C (not C++) program, with almost everything done in main()... I knew it was a bad design... but I did not anticipate the initially.

So, this was a really good lesson for me again, to "design for n" early.

No comments: