The Blog
To fix a design flaw or not to fix?
published May 24, 2010
You know the case: a situation in which you must decide whether you should do something about that design smell that was introduced earlier. You suspect that it will not have any effect to a whole system, but still, leaving it like this is not an optimal solution. There is a link at InfoQ.com to a blog post about sufficent design. In short, the blog is about this very same issue, a decision, whether to refactor existing design flaw or not. I feel that this question arises quite often and there is not one correct way to handle it.
The main point with this particular “flaw” is that it was carefully analyzed by a team and a decision was made to leave it as is. For me this is a valid argument to do so. Everything cannot be perfect, but I would like to know how much time the team has spent on the issue? Author states that the issue has been revisited many times, so I have to ask what if the code had been done differently at the first time, would they have saved time in the long run? I find this question intriguing and claim that companies are consuming huge amount of time and money to things that could just be fixed and forgotten. Worst cases are those where a team continually reopens issue without actually doing anything about it.
Shortcuts are unavoidable but they have to be managed. Firstly, you should never take a shortcut if you are dealing with an architecturally core component, that is a sure way to shoot yourself in the foot. If the component can be classified as “not-so-core”, then I see no fundamental error in leaving a minor flaw in the code as long as the flaw can be isolated from the rest of the codebase. Ideally, you would fix it but it is not always that simple. Secondly, I recommend keeping a document about architectural shortcuts that are left in the code. These things have a tendency to be forgotten, so a Toyota-A3-like document is a working way to keep team conscious about shortcuts.
No Comments to To fix a design flaw or not to fix?
Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
