Home » Author Archives: Edmund Kirwan

Author Archives: Edmund Kirwan

Edmund Kirwan
Edmund is a programmer with a telecoms company in Stockholm where he is currently working on a large-scale network simulator. In his spare time he thinks far too much about program-structure.

The structure of Netty

Netty‘s package structure is fantastic. Every programmer should study it; every system should mimic it; every project manager should print it out, slap on a wall, and say to developers, “That.” Netty is an, “… an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients,” but that doesn’t matter here as we are ...

Read More »

Evidence-based principles

A previous post tried to find objective correlations1, 2 between the number of times a method was updated and its structural properties. Given that the probability of a method’s being updated during a project’s lifetime depends entirely on whether that method partakes in the features arbitrarily desired by customers, it might have been guessed that such end-user whimsy would completely ...

Read More »

Does my method look big in this?

How big is the following Java method? public Collection getDescription() { SystemLibrary systemLib = registry.get(SystemLibrary.class); Analysis analysis = systemLib.getCurrentAnalysis(registry); return getDescription(analysis); } This humble method locates some sort of system library, retrieves an Analysis, and returns a description of that Analysis. But how big would you say it is? Would you say it is 3 lines of code long? If ...

Read More »

Is there any evidence for ripple effect?

This blog has droned on and on about ripple-effect husbandry (or lack thereof) and its determining the quality of source code structure. Ripple effect – whereby gently polishing code in one place radiates wobbles and cracks and shattering crashes far and wide – was defined in 1974 and has guided structural toil ever since. But does it really exist? Or ...

Read More »

Fundamental refactoring vs elaborative refactoring

Two types of structure Historian Benedict Anderson once wrote that, “All communities larger than primordial villages of face-to-face contact … are imagined.” In a sense, both class dependencies and package dependencies, too, are imagined. They’re not really there. And yet we expend vast energies in managing them. What motivates us to grapple with hallucinatory monsters? Well, this blog’s primary assumption ...

Read More »

The spectacular instability of good code structure

A previous post noted that source code structure decays because there are many more ways to build a poorly structured system than a well-structured one, and so, without strict structural guidelines, a system will inevitably explore deeper into disorder state-space until it finds the dark nirvana of ball-of-mud-ness from which few escape. This short post merely demonstrates the phenomenon graphically. ...

Read More »

Do interfaces terminate dependencies?

Response to a response A previous post explored the relationship between transitive dependencies and abstract methods in Java programs. Jaime Metcher penned an excellent criticism of the post on his blog, where he concludes: So I suspect that what Edmund has discovered is a correlation between the use of interfaces and modular program structure. But that just a correlation. This ...

Read More »

Is your code too concrete?

A post of note Mark Tiele Westra wrote a splendid post two years ago, “The ball of mud transition,” in which he elaborated on an idea nabbed from a Stuart Kauffman book. He writes, “Take 20 buttons and a ball of string, and scatter the buttons over the floor. Then take two buttons at random, and connect them using a ...

Read More »

Battle of the structures

Figure 1 shows a spoiklin class diagram of a well-structured package.                     It is well-structured because it makes dependency-tracing relatively easy. If we choose a class randomly – say ReusableStringReader – we can easily spot dependencies on that class and hence estimate the potential cost of changes made to that class, ...

Read More »

Interface over-segregation

Programmers easily spot bloated interfaces, and usually carry with them an assortment of, “Knives and stabbing weapons,” for just such encounters. A previous post presented an interface-efficiency equation and demonstrated an algorithm – fueled by this equation – to guide this butchery. A trickier problem to spot, however, is when the members of a family of interfaces have been cut ...

Read More »

Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Spring Interview QnA
  • Multithreading & Concurrency QnA
  • JPA Minibook
  • JVM Troubleshooting Guide
  • Advanced Java
  • Java Interview QnA
  • Java Design Patterns