Fragile – Handle With Care Reprise
Today I’m revisiting the topic of Fragile – Handle With Care in response to an Email from Philippe.
Philippe writes:
I am working everyday on such a handle with care software.
This software represents about 600 000 lines of C++ code. We are a team of 2 persons managing this software.
IHMO, the bunch or reasons are:
- Quick and dirty
- Copy and paste
- No refactoring
- Don’t fix if it is not broken
So, step by step, we have got functions more than 1000 lines, spaghetti dishes (call then call and new call and another call and so on), a lot of undocumented features, edge effects…
As a result: difficult to read, difficult to maintain, difficult to test.
My partner and I disagree about this strategy. But she is the leader of the team…
And when a refactoring of an ugly part of code happens, if any bug appears (and they appear because it is sooooo difficult to test), I get the comment: “You see, I was right, refactoring is not the good strategy.
In her mind, the software is not fragile but developers are too strong-arm people…
I can still hear a previous colleague of mine saying, “The most perfect method has only one line of code.” This was his form of hyperbole (gross exaggeration) emphasizing the software principle of single responsibility. This one principle alone, based on your description of the software, would resolve the capability of refactoring.
Why do I make that claim?
If your current methods utilized single responsibility you could easily (over time) add unit tests for methods to be Refactored.
If you had unit tests in place, then you could modify the software assuring you haven’t broken anything that is already in place, and that your new modifications (including new tests) work as desired.
There are many more principles and patterns that continue to add further improvements.
My initial thought is that when refactoring any existing code to enable new features is just as prone to breaking code. It has the same problem, too many dependencies.
It is a lot easier to start out with good coding techniques. So, at least for new code, don’t continue with the existing methodology. That may be just as difficult a thing to sell. I have had to do that in the past. Sometimes it may take years to really make the kinds of advances you would prefer to make.
Thanks for writing in to btaylor@sswug.org with your personal experience. I wish you the best.
Cheers,
Ben
SSWUGtv – AppFabric
With Stephen Wynkoop
did you miss the interview with Rick Garibay on his new book: Microsoft Windows Server AppFabric Cookbook? Well, here is another chance. Don’t forget, if you don’t have time to watch the show, you can download a podcast as well.
Watch the Show
$$SWYNK$$
Featured Article(s)
Denormalization Techniques for Relational Databases
Speeding the retrieval of data from relational tables is a frequent requirement for DBAs and performance analysts. One way to accomplish this is to denormalize the tables. The opposite of normalization, denormalization is the process of putting one fact in many places. This speeds data retrieval at the expense of data modification. This is not a best practice, but can be a reasonable practice if performance cannot be achieved against a fully normalized physical implementation.
Featured White Paper(s)
How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues
read more)
Featured Script
T-SQL SSN control digit calculator (for swedish personnummer)
This proc calculates the control digit for a swedish SSN (personnummer)… (read more)