I bet I know where your ugliest code is. I can usually find it when I visit a team. The first thing that I do is ask for an explanation of the architecture. I listen to the names and remember the key abstractions. Then, I pick one and ask about it. Does it have subclasses? Does it have plug-in points? I ask to see them, and that’s usually where I find the ugly code. It lives next to and below the architectural abstractions. It’s the “implementation code”, the stuff people write just to get something done.
Once, I visited a team in an organization with an SOA strategy. They had some very nasty code, but it looked good on paper. At the beginning of the project, they learned the pattern: design is something you with five or six classes that you arranged in an "SOA pattern." Once you did, you had a design and it was time to code. Any one of those classes became ten to twenty thousand lines of code. The developers knew it was okay because, after all, they had a design. And, somehow, the fact that they had a design made all of the cruft excusable. They had the clean bit and all of the other stuff just wasn't important.
Some of this, I think, is understandable. If you tell people that something is important, often they hear it as: everything else is unimportant. People just seem to be wired that way, but I think we're really remiss in the industry. We don't talk enough about this boundary.. the place where design hits "where you get the work done." It's a messy place, but it's a fertile place. It's where code for new requirements hangs out, and if you hunt, you can often find seeds of new abstractions there.
Design is never over and it isn't just a part of your system. It's something you have to do every day that you work on a system. If you're continually adding code there's no way you can expect that the first five abstractions you have in your software will be the only ones. They may not even be the key abstractions after a few months. You can ignore the problem and let more and more code fall outside the design boundary, but the right thing is to push the design boundary forward, to embrace all of the new code and assimilate it into your design. It will change your design. You won't be able to think about it in the same way, but that's fine. It's far better than working in the junk outside and wishing you were inside. And, tell you what.. there are a lot of people who are in that situation.
