Over a million developers have joined DZone.

What is a Tidy Codebase?

The best selling book "The Life-Changing Magic of Tidying Up" applied to software, with thoughts on philosophers and the perfect Caesar dressing

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I came across the book recently The Life-Changing Magic of Tidying Up. I think I got a sample on the Play Store and right away thought "Wow, this woman is an amazing writing voice." Now that I have read much of the book I know why:

1. It‘s a screed, delivered politely, like a witches curse delivered in a doll‘s voice

2. It is DEEPLY philosophical.

Nietzsche said he loves only that which was written in blood. Biography should be a screed, if you lived right. What's so awesome about this is that the author became obsessed with the problems of clutter at the age of five. Whether you are immediately convinced by each turn she takes or not, her rhetorical force is brilliant. (The etymology of the word graph is from the greek word for writing.)

Of course, at a certain point, I started to think, do we ever tidy in software? Part of the reason is the writer seems like a typical self-helper. But in fact, what happens is, in a turn that cuts to the core of one of my other favorite philosophers, David Hume, she attacks the illusions rather than the errors. It made me realize that the tidiness impulse in software is shrouded in illusion. Sadly, I think Uncle Bob's book does exactly what Ms. Kondo (one of my new heroes) does not do. That's not to say Uncle Bob's book isn't loaded with great ideas. But it's hanging itself on the notion of adhering to a model of purity. Rather than having the courage to face your illusions and try and gird yourself for having to ask how you get to escape the nearly universal indictments our industry keeps veering into.

The first thoughts that appeared to me were that there are obviously positional dynamics in coding: a programmer who is doing a greenfield piece that is in an area of interest is thousands of times more likely to produce something that is ordered and has some organizational dimension to it than someone sent down into an abandoned mine to scrape the cruft off of ossified garbage. But we‘ve all seen a million times how the village elders position themselves in the antechamber and make their manicured little stubs, then leave it to underlings to actually hook those up to services that pump real blood. In other words, delivering tidy organs by foregoing the actual process of starting the heart.

(I think when I finish this I have to go through Frankenstein. Cause, really folks, that‘s what we are doing most the time. Animation in software development is always a separate conjuring after the parts have been ‘assembled,‘ usually with a Perto‘s Law 80% of them passing through the clipboard.)

But then the other thing I started to realize in considering the crossovers was that we live in a fundamental illusion about tidiness that can be summed up quite easily: since we are doing software, and things are still changing, we really can‘t clean up now but we certainly mean to later. (In other words, imagine I am now speaking in that voice from The Wall that's saying "how do expect to get any pudding if you don‘t eat your meat?" "How can I clean this all up when I am still using all these toys? I can‘t put them away yet?")

Orderly Parts Yet Endless Design Variation

Shockingly, I kind of agree with this part. Well, that‘s not to say that we should allow ourselves to just surrender to mess making. No, that we should rather face it down and make it part of our process to achieve some semblance of order. Ms. Kondo's illusion-free definition is actually a world in which the joyful things are brought forth and then sent back in ways that are defined.

Of course, you can imagine how this would map to cooking. For instance, when I have a Caesar (nearly ubiquitous item that is an abysmal fake 90% of the time), I can tell immediately whether the garlic paste was rendered in a mortar and pestle. Caesar Dressing from a bottle is a complete joke. If I failed a blind test of detecting which was fresh v. bottled in a five round death match, I would probably accept hemlock after judgment. Anyway, after making Caesar a bunch, of course I learned the optimal way to make the paste efficiently. Does that mean I have drained the joy from it and turned it into an exercise of lifeless rote tasks? No. But let‘s remember, the preparation of a proper Caesar is going to consist of rendering a lot of components, especially if you make the croutons fresh, and grate the cheese and spin the romaine, and on and on. I saw a biography recently of Madhur Jaffrey where she waxes on how core spices, even if there are three or four, are like a painter's palette, that can mean the same dish can come out subtle different every time it is made. This is so true.

The patterns movement tried to theorize about how we could do this: learn component rendering variations that are internally ordered, and consistent and purposeful, but can, in combination, open up an infinity of possibilities. If I look inside a pattern, the orderliness of it is not really an issue: a Visitor either is one or it is not. If it is, I know where the two sides of the double dispatch are. That is not creativity crushing militarism. It's a realization that things have to be designed to both work internally in clear and reproducible (and consistent) ways, and they have to afford for combination with other elements. Open to extension, closed to changes.

Maybe tidiness in code should be part of the ABC (always be closing) credo. If we are always closing, in a sense, we are putting each thing away. We all know that codebases often fill up with god objects and weak abstractions. In part because the work is focused on the two ends of the spectrum: the infinite and the infinitesimal. In the middle is this realm where someone has to be able to say: ‘ok, there might be more changes coming to this, but for now, we can embody what is needed functionally, in a valid way, and thus forego accepting mess on a vague promissory note that will either never be paid down, or whose cost to pay off will grow as the moment of inception disappears into the past.

There is for sure an element of tidiness in patterns that is really appealing. It‘s pretty common to come across code that in itself is trying very hard to appear pretty and orderly, but that is in fact just presenting polished pieces arrayed in a sky devoid of constellations. The Toyota Case shows us that rot is not some easily explained phenomenon as we were led to believe. Frankly the Rot Generative Theory is kind of a classic scapegoat scenario: the greater men, in their increased wisdom know how to do things, and the lessers don‘t. When these little pygmy also-rans sneak in, usually through deception, they seed the code with their hobble homunculus. We must fight to keep out these vermin! To keep our code clean.

Uh, yeah, no..

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

technical debt,agile

Published at DZone with permission of Rob Williams, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}