66. You write small methods, yes?
We say we do, but do we really?
65. The ripple hypothesis.
Measuring ripple effect. Again.
64. How to avoid messy code.
If you could ask programs themselves how to avoid messiness, what would they say?
63. The structure of Netty.
Probably the best package structure in the world.
62. Improved radial encapsulation.
Making radial encapsulation more suitable for very large projects.
61. Are we still writing spaghetti code?
Is spaghettiness objective?
60. Evidence-based principles.
Do other principles show traces of objectivity?
59. Does my method look big in this?
The first of the SIPT principles examined: keep methods small.
58. Sip tea.
SIPT: objective principles redux.
57. A quick name-change.
"Impact set" and "Impacted Set" have swapped names.
56. Thank you, Mr Pearson.
Still looking for structural objectivity.
55. Is there any evidence for ripple effect?
Surely we should be able to see this most fundamental of concepts?
54. The 80% rule.
An indispensable coupling rule-of-thumb.
53. Fundamental refactoring vs elaborative refactoring.
Which type of refactoring are you doing?
52. Metrics considered charmful.
Vague notions are not enough.
51. The spectacular instability of good code structure.
Why unstable is good.
50. Do interfaces terminate dependencies?
Not quite an, "It depends," but close.
49. Is your code too concrete?
Don't neglect abstraction in the fight against structural decay.
48. Structure and emergent design.
Can well-structured systems ever just emerge?
47. Battle of the structures.
Which would win: semantic or syntactic structure?
46. Interface over-segregation.
Can interfaces be too small?
45. Bugs and cracks.
Why aren't structure faults as important as run-time faults?
44. Structural simplicity.
WWRHD: What would Rich Hickey do?
43. The structure of Apache Lucene.
The structure-of series continues with another Apache jewel.
42. Software engineering as ... engineering.
A tool software engineers might take from other fields.
41. Structure and the FBI.
An unusual application of your software's structure.
40. Breaking Bad ... interfaces.
How do you split a large interface?
39. The Blighttown corollary.
The importance of grand-scale structure.
38. Visualizing engineering fields.
A look at the competition.
37. Bad program structure: the complectation.
A minor oddity of structure.
36. The most important factor in software decay.
Why are programs poorly structured?
35. The four best refactorings.
Most refactoring is pretty; some is essential.
34. A funny thing happened on the way to the refactory.
Freedom of travel in the land of radial encapsulation.
33. Who's afraid of the big bad class?
How to refactor large classes.
32. Structural contingency (part one).
How to improve the intent of our code.
31. What's the opposite of duplication?
Strange that we still worry about duplication.
30. Dependency inversion: the structure logarithm.
A new use for an old principle.
29. The refactorer spectrum.
Refactoring is difficult and not everyone can do it.
28. Coupling and cohesion: failed concepts.
What's wrong with these two great concepts?
27. Asimov's three laws of refactoring.
Don't phone: it's just for fun.
26. The structure of FitNesse.
A structural peek under the bonnet of a great piece of software.
25. Structure-driven design.
Seriously, who didn't see this coming?
24. Interfaces in Java.
Some unfinished interface business.
23. The tragedy of package coupling.
Why package coupling still overpowers us.
22. Structure and information.
Gettin' entropic with it.
21. Structure and theorems.
Are programs theorems?
20. Structure and zombies.
All aboard the zombie-bandwagon!
19. Amplification revisited.
Investigating the bane of accidental interconnectedness.
18. ptainai, pronounced, "Peh-tain-eye."
An investigation into some hallowed advice.
17. The structure of Spring (core).
Finally, some light in the darkness.
16. Code autopsy.
An unsolved mystery remains in Ant: we're going back in.
15. Going Dawkins on god objects.
How to identify and slay these structure bad-boys.
14. The structure of Struts.
The excellent Struts gets the structure-analysis treatment.
13. How deep is your code?
Source code has many dimensions but its depth can be most dangerous.
12. The structure of Ant.
The search for excellent code structure continues with a look at Ant.
11. The structure of JUnit.
JUnit is a masterpiece. Its structure should be studied.
10. A simple suggestion to radically improve your package structure.
You don't need elaborate JSRs to build a better package structure.
9. How many classes and packages should you have?
What constrains your system's classes and packages?
8. The three greatest paragraphs ever written on encapsulation.
Encapsulation is a concept we all know and love. But where did it come from?
7. Serpents and sunbursts in source code structure.
What can we learn from viewing just the structure of a program?
6. Can we measure encapsulation?
Welcome to the world of potential coupling.
5. Spoiklin Soice.
A documentation and static analysis tool.
4. The Tulegatan principles.
A summary of some software development principles.
3. What is good source code structure?
And would you recognise it if it bit you?
2. The three-box model of software development.
Software development encompasses many, many things but sometimes a simplification helps.
1. What is source code structure?
Do we really know what we're looking for?








Ed Kirwan profile
Program
structure
musings.

Java Code Geeks
Dzone dude