Weblog for Developers at it-agile

it-agile has started a weblog targeted at developers: http://entwicklerblog.it-agile.de (german only).

Post bewerten

New Job

I changed jobs at 01-jan-2005. Now I work as an IT consultant for it-agile. it-agile offers agile software development and consulting / training for agile methods like eXtreme Programming. My new EMail address at it-agile is "stefan DOT roock AT it-agile DOT de".

Post bewerten

Slides of Talk: Refactorings in Large Projects

Here are the slides of my talk "Refactorings in großen Softwareprojekten" ("Refactorings in Large Software Projects") which I gave at the XP Days in Karlsruhe. Since the talk was given in german the slides are german also.

Post bewerten

Managing Module Dependencies in Large Systems

In larger projects it is nearly impossible to avoid degeneration of large scale structures without tool support. It is far too easy to import missing packages with one key-stroke in modern IDEs like Eclipse or IDEA.
My experience is that almost every projectwith more than 500 classes has unwanted dependencies between its modules (module = coherent set of packages). Often even cycles between modules occur.
There are some Open-Source solutions that help to avoid unwanted dependencies in Java projects or at least discover them early:

• Put every module in its own JAR file. An ANT build script can then discover unwanted depdencies during compilation and generation of the JAR files.
• If Eclipse is used: Define an Eclipse project for every module and let Eclipse manage the dependencies.
• The use of the Eclipse plugin model allows even finer control but brings some overhead with it.
• Define the allowed dependencies in a Fitnesse test. There is an easy to use solution named JDependFixture. Especially when you use Fitnesse already the your project JDependFixture may be a convenient solution.
• XRadar is also based on JDepend and checks dependencies between modules (in XRadar modules are called subsystems). XRadar uses a XML definition of modules and dependencies and creates a graphical representation of the existing dependencies. XRadar is especially convenient when a nightly build process is in place, for example based on Cruise-Control.

Post bewerten

Book: Refactorings in Large Projects

Martin Lippert and I wrote a book about Refactorings in Large Projects that is out now for review. We are very interested in your feedback. Simply write an email to stefanATstefanroockDOTde.

Post bewerten

Taxonomy of code smells

There is a new taxonomy of code smells.

Post bewerten

Large Refactorings at XP-Days Karlsruhe

I will talk about Large Refactorings at the XP-Days 2004 in Karlsruhe.

Post bewerten

Distributed Computation@home

SETI @ home was the first software for distributed computing at home: CPU time not used by the user is used for a really large distributed computation project. The experiences with SETI @ home were used to create a content independent platform for distributed computing: BOINC.
There are additional public projects for distributed computation using BOINC available at the BOINC link given above.

Post bewerten

Rich Client Patterns

Martin Fowlers book "Pattern of Enterprise Application Architecture" lacks patterns for rich client applications. On his website Martin Fowler has collected first patterns for rich client applications.

Post bewerten

Multiple Customers in XP

Ron Jeffries has written a short but interesting article about how to deal with multiple customers: Petition the King. He uses the metapher of villagers coming to the king regularly (one a month or one every two weeks) to explain their requests. The king has limited resources and decides about the usage of the resources.
In XP the king is not a developer since decisions about distributing resources is a bussiness decision not a technical desicion. Therefore king is a kind of super customer, head of marketing for a product company or something similar.

Post bewerten

Design in Agile Methods

One of the most controverse aspects of agile methods is the role of design. In eXtreme Programming the practice is stated explicitly: Simple Design.
Buzz words describing simple design are:

• You ain't gonna need it (the YAGNI principle).
• Keep it simple, stupid (the KISS principle).
• Design for Today.
• No Big Design Upfront (BDUF).

Two articles (available online) about the topic give further insights:

• Martin Fowler: Is Design Dead?
• Jim Shore: Continuous Design.

Post bewerten

Paper on Pair-Programming

There is a new paper on Pair-Programming online - only in german.

Post bewerten

Managing ANT scripts

In larger Java projects the ANT scripts tend to become complicated and hard to handle. Too often the ANT scripts produce incomplete results or need too much runtime. Eric M. Burke wrote down useful best practices for ANT scripts.
And he wrote a little tool that visualizes the dependencies of ANT targets: AntGraph.

Post bewerten

How to write unmaintainable code

Funny and true article: http://mindprod.com/unmain.html

Post bewerten

Visibility of Automatic Build

There is a cool kit for making the results of automatic builds (e.g. with Cruise-Control) visible: Bubble, Bubble, Build's In Trouble. And it costs less than 100 USD.

Post bewerten

XRadar: Structural Analysis for Java projects

We startet to use XRadar in a larger project for structural analysis, e.g. dependency checks between subsystems and packages.

XRadar is open source and combines a lot of useful small tools like JDepend and PMD to form a complete analysis suite. We integrated XRadar into our Cruise-Control build process and got helpful results about the structure of our system.

Post bewerten

Time Travel Pattern Language

I just discovered a paper describing the Time Travel pattern language for objects that change. The patterns address objects that have a browsable history of modifications where the modifications can have effects in the past and the future. These problems often arise with contracts where the time of making the modification can differ from the time where the modification takes effect.
Example: One week ago I buyed a new car. Now I send a notice to my insurance company. While the contract is modified tomorrow when my notice reaches the insurance company, the modification has to take effect one week ago in the past.
Once I was in a project at an insurance company and we had exactly the same problems. At the end we came to very similar solutions. Had we known the Time Travel pattern language we could have saved a lot of time, not only to find the solutions but more important to communicate the problems and the solutions.

Post bewerten

Unit Test Smells

The term smell was taken from the refactoring discussion. There a code smell comes from an ugly piece of source code that should be restructured (refactored) as soon as possible. Typical code smells are duplication of code, unneccessary indirections etc.
The term smell can be transferred to a lot of other “domains”, e.g. to the wide area of testing. This article is a first attempt to collect smells for the area of unit tests.

Post bewerten

C-JDBC: open-source inexpensive DB clustering

When searching for techniques to create Java enterprise applications without buying and using heavyweight products one should take a look at C-JDBC. C-JDBC is an open-source product that supports the RAIDb concept (Redundant Array of Inexpensive Databases): C-JDBC encapsulates several database instances behind a regular JDBC api. To introduce C-JDBC into a project existing code needn't be modified as long as all database access is handled via JDBC.

Post bewerten

Modular Software with PicoContainer

Most OO systems claim to be modular but very few really are. Normally OO systems have cycles between they modules. Even if there are no cycles the dependencies between the so called modules are chaotic and inflexible. A typical result is that developers can't instantiate a small set of classes for unit testing without having the rest of the system.
PicoContainer is an open-source project that provides a IoC-Container (IoC = Inversion of Control) that is very useful for defining and managing the dependencies between modules.

I collegue asked me once when I would PicoContainer into a project:

• Right from the beginning?
• Even for prototyping?
• When the system exceeds a certain size?

I think that projects should use PicoContainer right from the beginning and even for prototypes. Even for very small prototypes PicoContainer pays off measured in Lines of Code and it adds very small overhead to the project.
Adding PicoContainer later to a project results in refactoring and will therefore often not done.

Post bewerten