Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Why We Refactored JUnit
|
Posted: Jan 28, 2003 2:03 PM
|
|
> Why do people continually feel the need to rewrite rather
> than extend?
>
> Recently I investigated migrating from optimizeit to an
> open source code profiler, quite a number exist, each
> replicating the basics, none providing anything extra. If
> you look at the time lines for each generally one started
> when another finished. Rather than extending what was
> already developed, for no apparant reason a rewrite was
> considered the most appropriate.
>
>
> I wonder is this another example of rewrite rather than
> extension?
Sometimes, refactoring is necessary when a system can no longer accommodate certain types of extensions without breaking down. In the case of writing signature tests or unit testing Jini services, extending JUnit may have bloated JUnit to the detriment of developers that don't need those extensions.
But your question cuts to the heart of a very interesting design problem. Most of the basic building blocks of any software have, in fact, multiple implementations. For instance, there are dozens of filesystems (ext2fs, NFS, NTFS, etc), relational database implementations, or authentication frameworks. One could argue that, in the case of DBMSs, for instance, one would never have to write another DBMS, but could instead just extend MySQL or Postgres (well, that's 2 already). But would that be the right approach in every case?
I think extension of a system is effective only up to a certain level of system complexity. Where that level is, how much extension a system tolerates without being overburdened, depends on the flexibility of that system's design. In general, the simpler the inital design, the more extension a system allows.
But some systems, by their very nature, must be complex: For instance, a relational database, or even a testing framework, must have a level of complexity in order to deliver its benefits. Depending on where that level is, such systems tolerate only so much complexity before being overburdened. I think JUnit may have reached that level, at least with respect to the extensions we needed to make to it.
I'm a big fan of simplicity. But high levels of complexity are sometimes what differentiates a system in a positive way - it's what makes it unique. But that also makes those systems hard to extend.
I think that's not unique to software. For instance, the other day I was listening to a CD by a young singer (Vienna Teng, I believe). Her songs were nice, but were extremely simple. Their simplicity might tire one after listening to her songs for 50 minutes. As a musician, I could think of dozens of ways to extend her songs, to make them more interesting. On the other hand, when I listen to the Beatles (or Beethoven), I cannot come up with many ways to "extend" their music: They reached a level of complexity - perfection might be a better word - that does not tolerate much fiddling with their design (compositions).
To answer your question of why people sometimes feel the need to rewrite rather than extend, continuing the musical analogy, when Beethoven died some composers tried to extend his style. But most of us have never heard of them. The reason is that their attempts didn't work: Their style ("design" or "architecture") lost its coherence. Others, however, instead of extending his style, went on to rethink - refactor - the symphony, the opera, the song. They were the Schuberts, the Schumanns, the Wagners, or the Beatles.
I think similar principles apply even to political systems. For instance, the American revolutionaries didn't want to extend the British imperial system, but instead went on to "refactor" the social contract between the citizens and their government. So a revolution (refactoring) was necessary, because the old system couldn't accommodate the requirements (extensions) of the new design.
The beauty of open source is that when you reach the inflection point of a system's design complexity, you can take its main ideas and build something new upon those concepts. It may not always be worth doing, but it almost always leads to interesting new ideas. In the case of SuiteRunner, one such idea is coming up with a cleaner API to interface with. That might or might not be the "perfect" design (most likely, not)... So others may end up refactoring SuiteRunner to suite (no pun intended) their needs....
|
|
Previous Topic
