It was supposed to

January 31, 2008

be rainy with sleet and strong winds and then snow. Nothing happened. What happened to the forecast?

Advertisements

Why Writing New Code is Better than Changing Existing Code?

January 30, 2008

Very few developers today write new ground-breaking software. Much has been written about this and I’ve found these posts to be very insightful (link1, link2).

The majority spend large amounts of their time understand existing code, and then modifying to either fix or extend it.

Now the question I’m asking myself these days is that, if the largest amount of programmers’ time is being spent in either fixing or extending code, then why is it that large complex software is never bug free or that the number of bugs never go down to a point where they can be safely ignored? Why is it that even though so much programming time is spent on fixing and extending, testing costs just seem to grow exponentially as time goes on?

My take is that the activity of fixing and extending software almost always involves modifying existing code. A bug would be fixed by adding an if statement to handle that specific error case.  A new feature can be added by adding a new case statement to a switch block. That action of modifying code increases the probability that a new fault would be introduced. In my opinion, the whole premise that in order to fix or extend functionality, existing code should be modified, is flawed.

Rather, developers should fix or extend software by adding new code. Freshly written new code is almost always better written than previous versions simply because of the fact the next developer has the benefit of hindsight.

After all when you are writing new code for a specific requirement or bug, you are definitely adding value. On the other hand, when you are changing code, you are changing value, but you’re never quite not sure whether  you are adding or subtracting value.

What we need to do these days is to acknowledge that mistakes in development are natural and normal in a development cycle, and that developers should not be penalized for them. They should be encouraged to design software that is maintainable by extension rather than modification.


On Running with Audio Books

January 30, 2008

So I tried running with audio books, but Gold Gym’s music system was so loud that I couldn’t understand a single word that that the narrator was saying.


<blogger’s block>

January 30, 2008

I started off with a post on software development that had been rolling around in my head while I was running. I wrote a paragraph or two and then hit a brick wall. Maybe its late and I’ll try again later tomorrow.


On Running …

January 28, 2008

I’m thinking about running some local races this year and I’m training accordingly. One of my coworkers suggested I use audio books to get my mind of the constant pounding on the pavement, rather than listening to my usual music. Normally, I don’t care for audio books, but if this helps, I’m definitely changing my reading habits.


Exploring XPCOM

January 28, 2008

I’ve been reading about XPCOM and Mozilla development. I came across a Component Viewer for XPCOM based components here. It only works with the unsupported Mozilla 1.x browser and not Firefox.

… any ideas how this thing works with Firefox?


Saturday Night Movie

January 27, 2008

Watching The Fountain right now. The soundtrack is pretty eerie and ghostly. So far I like it. Here’s the trailer and the link on IMDB.