Comments on: Software erosion in pictures – Findbugs

By: Software erosion and package tangles « sutts on software

Software erosion and package tangles « sutts on software — Sat, 17 Jul 2010 07:00:41 +0000

[...] a comment, Emeric questioned whether cyclic dependencies at the package level are anything more than a smell [...]

By: The parable of the two watchmakers | Deconstructing Software

The parable of the two watchmakers | Deconstructing Software — Mon, 30 Mar 2009 14:15:02 +0000

[...] Because, mostly, we only pay attention to aspects of modularity and component-ness at two levels of granularity: low-level code (classes, methods) at one end of the spectrum, and unit of deployment (jar, dll) at the other. Everything in between we tend to treat as a largely amorphous blob comprising hundreds or even thousands of interacting entities. Even in those case where we do have meaningful abstractions/layers between the low-level code and and the unit of deployment, these are generally invisible and unmeasured. In this context it is hardly surprising that they will tend to degrade over time. [...]

By: David Hovemeyer

David Hovemeyer — Sun, 14 Dec 2008 18:42:46 +0000

You’re right – the architecture of FindBugs is not pretty. I’ve occasionally thought about doing a reimplementation, but it would be a huge amount of work.

By: Raoul Duke

Raoul Duke — Fri, 05 Dec 2008 16:54:23 +0000

@revisions

cool. at least one important difference between you and me is that you actually *do* things; thanks for being somebody who really does stuff!

(some day down the road in your future copious free time i wonder if you could animate the graphs morphing along, so there’s no fade even? i’d hazard to guess that there is some code lying around somewhere on the web to let one do something like that, although i certainly don’t know where.

or maybe simply having them lined up vertically statically one after another in a long strip of images would let people scroll the document to easily compare? like, if 2 (or 3?) fit on a screen at a time? maybe at 3 then they’d have to be horizontal since most monitors are wider than they are tall.)

By: Ian Sutton

Ian Sutton — Fri, 05 Dec 2008 10:53:49 +0000

@Raoul Duke
Thanks for the compliments and the beautifully couched criticism
Between you and me, I’m crud at graphics (perhaps that’s why I like tools that draw things for me). But I had another go and perhaps this one is better.
Hardest bit is the juggling between trying to have something which is quick and snappy (< 1 min) but at the same time useful – animated gif may have been a bad call there. So I also did yet another version, but this time as swf (with a pause button).

By: Ian Sutton

Ian Sutton — Thu, 04 Dec 2008 00:00:27 +0000

@Otavio Ferreira Hi Otavio. Nice posts, and I kicked off another round of ping-pong on your modularity piece. Agree on the stay in touch!

By: Raoul Duke

Raoul Duke — Tue, 02 Dec 2008 02:21:03 +0000

very awesome post.

…up until watching the animated GIF. the cube rotation thing does not add didacticism, it pretty much destroys it. please, please, please, meditate deeply upon your sin and post one that just fades between stages, or something like that.

By: Otavio Ferreira

Otavio Ferreira — Sun, 30 Nov 2008 13:24:33 +0000

Hello Ian. I really like your post, it's very well set out. I've been studying dependencies among modules for a while, and I must say that I really understand the problem you're presenting here, as well as your suggestions that would make the architecture depicted above better. BTW, Structure101 seems to be a very interesting software indeed, good stuff! Ian, you might be interested in reading other two post I wrote for the MIH SWAT blog, namely Object Orientation’s Worst Enemy and Dependency Inversion: Killing Gorillas and Butterflies, as they talk about the same subject. Any thoughts? I kept our conversation going on Good software modularity. What exactly is it?. Let's keep in touch. Cheers!

By: Ian Sutton

Ian Sutton — Fri, 28 Nov 2008 12:06:58 +0000

Emeric : Them's good questions. I'll follow up in a separate post.

By: Ian Sutton

Ian Sutton — Fri, 28 Nov 2008 11:24:50 +0000

@Rahul That is very likely overstating things (though smiley duly noted). The impact of this kind of erosion will be predominantly on the internal development - I would speculate that their rate of change has degraded over time and the level of coupling at the class levels leads to more side effects (though tests can counteract that in many cases). But this is not the same saying that they should tear it up and start again. There is a paper on this subject in IEEE Software, looking at a couple of other open source Java code-bases. Paraphrasing liberally, the thrust here is that there were recurring phases (called "structural epochs") in the code-base evolution where development of new features largely ground to a halt while the team was striving to rescue the architecture (combat erosion). In the cases, observed, however, these efforts were only moderately successful, and were generally more about moving excessive complexity around rather than actually reducing it...