I, like many developers, was raised on the idea of getting the database complete before writing the code. The database was the foundation of our application, and building a house without a finished foundation is insane. Also, don’t even THINK about changing the foundation once the house-building has begun. If you MUST change the foundation once development has begun, you’d better have a damn good reason.

When I started to learn about agile and lean software development, I learned about emergent design. Build only what you need for the small piece of the application you are currently building. That includes database, domain objects, services, DAL, everything. It felt very weird to be building membership stuff with no idea of how the rest of the database was going to look. Of course, there is an overall IDEA of what the design MIGHT look like, but until you need it, don’t build it.

There are two main reasons I think emergent design results in better designed software:

You Are Only Thinking About The Thing You Are Building Right Now

On the surface, this might seem like a bad thing. Focusing on the piece that you are currently building helps you to focus on the needs of the functionality you are adding and refrain from building “hooks” into a module for functionality that may never be added, or maybe added in a totally different way. Thinking about future modules (or already implemented modules for that matter) can influence the way you design this small piece of the application as well. Focusing on the fact that other modules need to “use” this module is different than thinking that module x needs to use this module. That thought can lead you to build in coupling between the current module and module x.

You Are Forced To Constantly Change The Application

Again, this may seem like a negative, but changing small pieces constantly makes the application easier to change. If I have to constantly change a module here and a module there every time I add new functionality, I am forcing myself to make each module easier to change. It allows me to see where pieces of my design become brittle and hard to change. This refactoring to ease change leads to loosely coupled, highly cohesive systems, which is what we’re are trying to design.

Use The Force, Luke

In the beginning, it may take some faith and some suspension of disbelief, but once you start seeing designs that are loosely coupled, highly cohesive and easier and easier to change, you’ll start to understand what the original XP Masters were talking about. Just stick to your principles, of writing a spec (test) before you build each granular piece, write the simplest thing that will make that spec pass and then refactor to clean up duplicate or complex code.

Got your attention? Good. It really doesn’t.

Developer’s, in general, are always afraid to let other developers see they’re code. They are afraid they won’t measure up. Since 90% (or better) of the world’s developers are male, maybe that insecurity of what’s under the covers carries over into development. Maybe we just DEFINE ourselves too much by our profession and our coding prowess. I am as guilty as anyone. I am always afraid someone will look at code I’ve written and think that I am a fraud. They’ll look at my tests and get the idea that I don’t know what I am doing.

There are two main problems with this approach:

Un-Critiqued Code Doesn’t Get Any Better

If you are truly serious about getting better at coding, the best and surest way is to let other people thrash it. Let others download it, play with it, give you feedback and send you patches. You have to have a thick skin, because some criticism will be blunt and sometimes just plain hurtful. Understand that even underneath the crap-crusted exterior of a complete flame, may be a small golden nugget of information that might change the way you code for the better. Don’t be afraid to wipe the poo away.

They’re Going To Do It You Anyway

Every group has it’s assholes. The development community has quite a few, and they are a flatulent bunch. They will blow wind about every aspect of your approach from the initial architecture to the final execution. Again, take all that in, wipe off the muck and see if there is anything useful. If not, feel free to ignore them, if so, in a year you’ll be seeing that same asshole commenting somewhere else on the blogosphere about someone else’s raggedy approach. Be assured that they are not moving forward as fast as you, if they are only giving advice and never taking it.

Be True To Yourself

So back to my original statement: “It doesn’t matter if you don’t know what you’re doing.” Put your code out in the world as your approach not trying to purport yourself as an expert, and you’ll see that you get a lot of great advice from lots of great people who were once right where you are now. Even if all you do is ask another coder you know or work with to review your code, you’ll reap whirlwinds of benefit.

OK, I’ve been remiss in my duties as a blogger I know. Can you forgive me? Both of you? C’mon! It was only a couple of weeks. I promise to be more diligent in my posts in the future. So… we cool? Ok.

I am really posting to let you both know that I will be speaking at Iowa Code Camp tomorrow. I have two talks. One on BDD, of course, and one on The Opinionated Web Solution. This is a new talk that is about arranging web projects in a solutions.

If you happen to be in the Des Moines area, drop by.

~Lee