3 ms·

I'm dealing with some dirty code now, so this really resonates with me. But I disagree on two points: 1) Dirty code has "concepts that don't map to the domain"

I'm dealing with some dirty code now, so this really resonates with me. But I disagree on two points: 1) Dirty code has "concepts that don't map to the domain". This is true at one level of abstraction. An Orbitz-like application is going to have objects representing flights and rental cars and hotel rooms. But a couple of levels down, there are highly non-intuitive search algorithms with all sorts of concepts that have no obvious connection to the domain. I think the real point is not to expose low-level abstractions higher up. 2) "Dirty code inhibits the formation of an ownership culture". A huge problem with dirty code is that it is permanently owned by the author. No one else can possibly fix or extend it. What you really want is code so transparent that anyone can get into it quickly and easily.

samstokes 16y ago
A huge problem with dirty code is that it is permanently owned by the author. In my experience, most dirty code isn't really owned by anyone. Person X wrote a widget, then something changed elsewhere to make it obsolete, but there wasn't time to rewrite it to properly reflect the new situation, so instead Person Y added some quick workarounds. Now neither X nor Y fully understands the widget any more. (Y might equal X - it's hard for a good programmer to feel ownership for a rush job they know to be suboptimal.) Later, there's a codebase-wide optimisation drive, driven by person Z. Z asks who owns the widget, both X and Y shrug, so Z skims through the code, comes to his own incomplete understanding, and duct tapes over the patches from the previous rush job. In this way the widget becomes a no-man's-land, where everyone goes to add a quick hack, but nobody wants to take enough responsibility for to nuke it from orbit.
- geophile 16y ago
  I've spent my career mostly at startups, and I see a pattern in which some critical piece of code is written by one person. Over time, or because the author doesn't value (or recognize) clean abstractions, the code becomes impenetrable, and only the author can maintain it. But I can see how a series of owners can produce the same situation.
chadaustin 16y ago
1) Thanks for the clarification. The problem we ran into at IMVU was that the original product (an instant messenger add-on) had concepts that no longer applied once our product pivoted a few times. These stale concepts hung around and prevented us from making changes to our core product. A 3D scene viewer consisted of at least 5 classes: SessionWindow, PresenceWindow, AvatarWindow, CustomWindowHelper, and RenderedWindow. Now the scene viewer is one class... SceneViewer! I'm a strong believer that mapping your code to customer-visible product elements is high-ROI. 2) Regarding ownership culture - that's exactly what I meant. If code is clean, anyone is comfortable touching it. If it's dirty, people start going directly to its author. Clean code is an organizational lubricant.
StrawberryFrog 16y ago
concepts that don't map to the domain ... there are ... a couple of levels down ... concepts that have no obvious connection to the domain There always are. I took it to mean that dirty code has concepts that don't map properly to the domain, i.e.: 1) Objects that claim to map to the domain, but do so badly, or do so partly but fail at this in obvious and subtle ways. 2) Leaky abstractions A huge problem with dirty code is that it is permanently owned by the author Or worse, nobody will go near it. Coders move on or forget the hack that they did in the crunch, so the author may be absent or disavow it. As commented elsewhere, he meant to say "Dirty code inhibits the formation of a good, collective ownership culture"

samstokes 16y ago

A huge problem with dirty code is that it is permanently owned by the author. In my experience, most dirty code isn't really owned by anyone. Person X wrote a widget, then something changed elsewhere to make it obsolete, but there wasn't time to rewrite it to properly reflect the new situation, so instead Person Y added some quick workarounds. Now neither X nor Y fully understands the widget any more. (Y might equal X - it's hard for a good programmer to feel ownership for a rush job they know to be suboptimal.) Later, there's a codebase-wide optimisation drive, driven by person Z. Z asks who owns the widget, both X and Y shrug, so Z skims through the code, comes to his own incomplete understanding, and duct tapes over the patches from the previous rush job. In this way the widget becomes a no-man's-land, where everyone goes to add a quick hack, but nobody wants to take enough responsibility for to nuke it from orbit.

geophile 16y ago
I've spent my career mostly at startups, and I see a pattern in which some critical piece of code is written by one person. Over time, or because the author doesn't value (or recognize) clean abstractions, the code becomes impenetrable, and only the author can maintain it. But I can see how a series of owners can produce the same situation.

chadaustin 16y ago

1) Thanks for the clarification. The problem we ran into at IMVU was that the original product (an instant messenger add-on) had concepts that no longer applied once our product pivoted a few times. These stale concepts hung around and prevented us from making changes to our core product. A 3D scene viewer consisted of at least 5 classes: SessionWindow, PresenceWindow, AvatarWindow, CustomWindowHelper, and RenderedWindow. Now the scene viewer is one class... SceneViewer! I'm a strong believer that mapping your code to customer-visible product elements is high-ROI. 2) Regarding ownership culture - that's exactly what I meant. If code is clean, anyone is comfortable touching it. If it's dirty, people start going directly to its author. Clean code is an organizational lubricant.

StrawberryFrog 16y ago

concepts that don't map to the domain ... there are ... a couple of levels down ... concepts that have no obvious connection to the domain There always are. I took it to mean that dirty code has concepts that don't map properly to the domain, i.e.: 1) Objects that claim to map to the domain, but do so badly, or do so partly but fail at this in obvious and subtle ways. 2) Leaky abstractions A huge problem with dirty code is that it is permanently owned by the author Or worse, nobody will go near it. Coders move on or forget the hack that they did in the crunch, so the author may be absent or disavow it. As commented elsewhere, he meant to say "Dirty code inhibits the formation of a good, collective ownership culture"