April 02, 2006

a problem with efficient coding?

i write this in my own words. so it is quite possible that there are a few embellishments that get added (un)intentionally. however, the moral of the story is what is important here.

back in the days of ww2, the germans gained a psychological advantage over the allies (especially the british) by wreaking havoc with their 'v1 flying bombs'. it took a long time and a good number of failed attempts for the british to come up with measures to counter these 'demolition birds'. however, there was one specific battle (possibly more) where the v1s proved to be a mere annoyance and posed no real threat, in spite of their heavy destructive ability.

antwerp was a huge port in belgium and was an important german stronghold, it being the second largest harbor in all of europe. the allies captured it and drove the germans out of it, which fuelled german attempts to destroy the port and the british ships docked in it. so what do they do? send out their v1s.

the result: most of the v1s ended up destroying dutch villages (which were evacuated, fortunately) that were roughly in between the v1 launch sites and the target, antwerp. this would seem really strange considering the fact that the germans had really smart scientists and engineers. this baffled the british and american scientists as well, who studies the v1 trajectories day in and day out just to figure out what was going on. and when they eventually did figure out what was going on, it was protected as a confidential military secret.

all of us know how projectiles work - so did the german engineers. they measured the distance ('range' in projectile terminology) between the launch sites and antwerp, inclined their v1s at 45 degrees for maximum range, calculated the actual distance that the v1s would have to travel, and filled them with the required amount of fuel. this sounds like a perfect plan, doesn't it? can you think of any problems with this approach?

well, it was the inclination. the machinery available wasn't accurate enough to incline the v1s at *exactly* 45 degrees. (disparity between theory and practice!!). the error was really very minute, but the problem was that this minute error was with the angle of inclination (of all things!!), which ended up throwing the v1s completely off-track.

now comes the question - how could the germans have avoided this problem? no . . . . . not by throwing more money into developing machinery with lower error. they should have behaved in a little less miserly fashion. yes . . . . . all they needed to do was to fill in a little more fuel than they did, and this would have provided thrust for a little more time, increasing the maximum height of the projectile and in turn, increasing the range.

A (poor) illustration:



well, i'm not contending that, by doing this, the germans could have turned the war and the world would've been a different place today but . . . . . you never know!!

now, putting this into context . . . . . i learnt this fact from my (extremely knowledgeable) manager while we were pondering over why we weren't getting the results we expected, even though we were doing everything according to (the theoretical) plan. he then narrated this little story to me and said that maybe we're overlooking something, just like the germans did.

and this way, he succeeded in adding to an already long list of concerns that i need to be worried about while coding. i have this habit (which i was proud of till this day) of keeping things as efficient as possible starting from the smallest modules, instead of the other approach wherein, people initially just get things to work, and then go about optimizing stuff. now when i think about it, there doesn't seem to be much difference between 'being efficient' and 'putting in the exact required amount of fuel'!! :(

some people might argue that it's not the same situation with software. there are no physical conditions like wind resistance that can affect the performance, and that software runs in a perfect 'environment'. this may or may not hold depending on the issue that the software is addressing. it certainly doesn't hold when dealing with statistical and probabilistic models to solve problems, which is what i do.

what do i do?

-w

0 Comments:

Post a Comment

<< Home