Skip to main content

Agile architecture part II, SOLID or YAGNI?

In a previous post about agile architecture I reasoned why big design up front isn’t a good solution to the problem of handling complexity in software. The best solution is architecting your application to avoid complexity as much as possible. At the end of the post I suggested reducing complexity by not implementing anything you don’t need right now. This principle is well known as YAGNI, short for You Aint Gonna Need It. Don’t implement anything you don’t need now. This will keep complexity down making it simpler to extend when you do need it. There’s another solutions to handling complexity though. You can reduce complexity by modularization. In software engineering we’ve got the SOLID principles for this. Unfortunately the SOLID principles seem to go against what YAGNI tells us. They tell us to add interfaces, separate out our dependencies and add all kinds of structures to our code that we don’t need just yet. So what’s it going to be SOLID or YAGNI?

The idea is actually quite simple. Lets look at a purely theoretical piece of software consisting of one component that can have ten states. Now we want to implement a new feature that will cause our piece of software to double in size. You’d think it would double in complexity too but you’d be wrong. When we add a similar component with ten states the total amount of states isn’t 10 + 10 = 20 but 10 * 10 = 100. So instead of doubling the complexity we’ve squared it. This is why spaghetti software will get unmaintainable really fast when size increases.

What we can do to contain this complexity is by separating our software into components or modules. If we construct our software so that we can reason about it’s parts instead of the whole thing we can still fit it in our heads. We don’t need to look at all the 100 states in the previous example when we can the software as separate modules or components. Then we only need to reason about the separate parts and the thin interfaces where they touch each other.

This is where SOLID comes in. I won’t get into the details of the SOLID principles here. Just bing them and you’ll find enough hits to explain them. But they give us guidelines on how to partition our software, hiding complexity behind well-defined interfaces and separating components so we can handle them by themselves giving us the ability to handle each part of our code as if it was alone in the world.

So I think we can use them both YAGNI does not tell us to refrain from adding lines of code we’re not going to need. YAGNI tells us not to add complexity we don’t need. SOLID is about removing complexity by separating out components.


Popular posts from this blog

Using xUnit.Net with .Net 4.0

I’ve been using xUnit.Net for a while now. It’s just a tiny bit cleaner and slightly less abrasive than other .Net unit testing frameworks. Leaving out unnecessary stuff like [TestFixture] and shortening Assert.AreEqual to the equally clear but shorter Assert.Equal don’t seem like big improvements but when you type them several times a day tiny improvements start to add up. I also like the use of the [Fact] attribute instead of [Test]. It shifts the focus from testing to defining behavior. So how do we get all this goodness working with the Visual Studio 2010 beta?

Running a Git repository on Ubuntu using Gitosis

20I’ve been using Git for a couple of small projects that I’ve been hosting on but version control for my bigger ‘secret’ projects still runs on a windows machine with visual svn server.Now that I’m starting to use Mono for a couple of projects so I’m playing with linux more. Last week I decided to try to try out gitosis on an ubuntu server. I found out it’s pretty easy to use when you know your way around git but for a noob like me some things weren’t immediately clear. Eventually I solved most problems I ran into, so I decided to write up the steps I took to install gitosis on ubuntu 10.04

Android development resource links

I've been playing with the Android SDK and I have a growing list of bookmarks to Android dev resources for my own use. I thought the best place to keep them would be here on my blog. That way other people can benefit too. I'll keep updating this list so feel free to add suggestions in the comments.