« Class Splitting and the Graph View of 'Extract Method' | Main | The Deep Synergy Between Testability and Good Design »

June 29, 2010

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341d798c53ef01348515e4f1970c

Listed below are links to weblogs that reference Festering Code Bases and Budding Code Bases:

Comments

Dave Rooney

"The fact that we know that budding code is more cost effective over time doesn’t change the perception of the cost at the time of change."

You know that and I know that, but I have seen dozens of developers who either don't know it or don't believe it.

Changing how we think about building software is a challenge similar in scope and complexity to changing how we thought about smoking and driving while intoxicated. Seriously. It will take a couple of generations for the change to take hold, and even then there won't be 100% adoption or even acceptance.

The last paragraph, though, does allow some rays of hope to shine through! How would you see a language promote budding vs. festering? I could see an IDE provide some tools around near real-time code smell identification, but that would require people to actually use an IDE! I'm working in the telecom world right now, and most developers use simple text editors (let the vi/EMACS wars begin!).

Philip_schwarz

In Clean Code, Jeff Langr says "We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviors.".

To those who fear that a large number of small, single-purpose classes makes it more difficult to understand the bigger picture, he asks: "Do you want your tools organized into toolboxes with many small drawers each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?".

These opposing approaches to growing one's toolbox seem to map to your two approaches to growing code: budding and festering.

When we have a new tool to add to the toolbox, the fact that we know that putting the tool in a newly labelled drawer is more cost effective over time doesn’t change the perception of the cost at the time of change, so we are always tempted to just throw the new tool in an existing draw.

Esko Luontola

Nice observation! I'm thinking that it would be interesting to collect such festering-budding metrics from code bases automatically, so I filed a feature request for one code metrics tool. :)
http://jira.codehaus.org/browse/SONAR-1652

andypaxo

I agree completely.

You mention "doing something clever" with languages or IDEs to make budding desing easier than festering design.

I find that unit testing / Behaviour Driven Desing does this. It is much easier to write tests for small, single purpose classes and methods with a small amount of behaviour. As soon as you start adding a lot of behaviour to a method it gets much, much harder to test it comprehensively.

Sammy Larbi

A while ago I was thinking of psychological barriers in software development on my blog (posted at http://www.codeodor.com/index.cfm/2009/3/24/Passive-Barriers-in-Software-Development/3055 ), and one of the things I thought would be cool to see was an IDE that implemented annoyance driven development.

The relevant bit from that post:

Annoyance Driven Development. This isn't one that I know how to turn on or off, but I think it would be a great feature to have in IDEs or text editors: it gets slow when your methods or classes or files get too big. This would be a great preventative tool, if it exists. I guess it falls back to using test suites and code analysis to provide instant feedback that annoys you into doing the right thing.

Fcarucci

I especially liked the concept that at the time of change, just adding code to an existing method, and not refactoring to a better structure, is perceived as more cost effective, but it’s just accumulate technical debts, that over time cost money in the form of interests. Same concept can be applied to write unit tested code: it seems to cost more at the time of change, but costs less in the long term, by flattening the curve of cost-of-change.

Jens Schöbel

Very high level very good approach.

Why do you think programmers want a file of thousands of lines of code?

They don't want. The company philosophy drives the behavior of programming. If everybody is doing the same, you just will follow them. It is easy to look one step forward. It is easy to see ten steps into the future. But is requires courage to make a stand against the mass.

I honor the guys who are willing to make a difference and try improve.

Excellent read. :)

Juan Pablo Olguin

Really, excelent Post Michael, I cannot agree more. The relationship with testeable code is indeed interesting.
One little thing about what you mentioned about what we would improve with a clever IDE design or new tools. The best example i was thinking of is one of the simplest but most used refactor nowadays IDEs offer: 'RENAMING'.

Have you notice how much impact it has had (and is having) on improving readibility? and by transitivy, on maintainability?
Thanks!

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment