Thursday, April 03, 2008

When do you decide to do a redesign of your software?

I'm working like hell right now on the implementation of a new feature of our software in oder to support flow charts. With the flow charts, and accompanying editors and publication engine plugins, an author can add flow charts to describe a business process, work flows and stuff alike.

The flow charts are, in the tradition of the Sevensteps approach, object oriented and stripped from whatever visual markup that could be there. If you want a green flow chart element: fine. But, first create a style for that and apply it to the flow chart object. Want a italic text? Sure, but change the style to do that.

This approach enables us to have a true single source system and reusable content objects in our CMS-es. But, yesterday I was working on the styles editor and the flow charts editors and found a flaw in my design. The handling of actually applying the styles was programmed in the style editor, instead of in the flow chart object. Although the style editor worked beautifully, I realised my mistake when working on applying the styles for the actual flow chart objects. I found myself reimplementing the same code again.

Although I am under enormous time pressure, I decided to change that implementation and moved the code for applying styles to the place where it belongs: the flow chart objects.

It all took another day of my available time for all this (and I am running out of time already), but I am assured to know that later on I will be glad I did it. Right now it feels like time wasted, but I know better than that :-)

I have one rule that I don't move away from, no matter what: if you decide to do something, do it right, or don't do it. If you do it wrong, and - worse - if you know that it's wrong, it will bite you later on. It might take a day, a week, a year: you will regret it.

So, the answer to the question is: you do a redesign if you know that it's wrong. Don't change it and it will haunt you. Do it over again, and you'll be happy in the end.

Bye,
Bart

1 comment:

Mike Eberhart said...

My own answer to your question is a simple one: constantly. I am a firm believer in continuous improvement through relentless and incremental refactoring of my code. I take nearly every opportunity to improve my code, knowing the improvements will save me time in the future. But, I also tend not to suffer from time-constraints much, since my underlying code is nearly bug-free from all the refactoring over the years, I have much more time to implement new features (which, will inevitably be incrementally improved upon constantly as I continue working with it). The pursuit of perfect code... what more is there?