Mendelt Siebenga

Agile architecture part II, SOLID or YAGNI?

Mendelt — Wed, 15 Jul 2009 21:07:58 +0200

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.

Using .Net 3.5 features in BlogEngine.Net widgets

Mendelt — Tue, 30 Jun 2009 21:12:30 +0200

I’m getting quite used to C# 3.0 and .Net 3.5 features. So it took some getting used to not being able to use ‘var’ and linq-to-objects when writing the ‘My book-pick’ widget for BlogEngine.Net you see on the right. Eventually I just gave up and hacked the Web.Config. It turned out to be really easy to switch BlogEngine.Net to C# 3.0.

First you have to set the compiler for the code-behind to .Net 3.5 (somehow the version numbers for .Net 3.5 and C# 3.0 are a bit mixed up, just ignore this and use the code I’m using here) You do this by adding this section to your web.config.

   1: <system.codedom>

   2:     <compilers>

   3:         <compiler language="c#;cs;csharp" extension=".cs"

   4:             type="Microsoft.CSharp.CSharpCodeProvider,System,

   5:             Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

   6:             warningLevel="4">

   7:         <providerOption name="CompilerVersion" value="v3.5" />

   8:         <providerOption name="WarnAsError" value="false" /></compiler>

   9:     </compilers>

  10: </system.codedom>

You need to add this just inside the <configuration> tag.

Now you’ll be allowed to use ‘var’ keywords and auto-properties. But of course we won’t stop until we have extension methods and linq.

Actually this is quite easy. Just add a reference to System.Code by adding this key to the <assemblies> section in <system.web>

   1: <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

Have fun coding your widget!

Agile architecture, embrace change through reduced complexity

Mendelt — Sat, 27 Jun 2009 16:33:06 +0200

Software development can sometimes be very counterintuitive. For example, when people started building larger software systems halfway through the last century one of the things they discovered was that changing existing software is often far more difficult and error prone than building new software. Most developers rediscover this somewhere in their first year of being a professional developer. They start out with a new project and as time goes by changes start taking more and more time, this can be very hard to explain to a client and usually we don’t until we get completely stuck and tell the client we need to start from scratch. I think this practice has been responsible for most of the bad reputation software development has.

So if changing software is such a hard thing to do we just have to do things right from the beginning. Analyze all requirements the client could ever have, make a design that incorporates all those requirements and then build that, this way we should never have to change anything. Sounds like a great plan but there are three things that make this quite impossible. Clients, stupid programmers and the rest of the world.

First of all clients don’t know what they want. It seems like I’m just trying to shift blame away from developers like me but I’m not. This is just a fact we have to deal with in our profession. Clients are not omniscient. They learn during a project and learning makes them change their mind. Of course there are ways to make sure clients don’t do silly things like this. You can spend more time doing requirements studies so they have a chance to change their mind before we start building or we can write everything down in big contracts so clients aren't allowed to change their mind anymore.

But then we encounter our next hurdle, stupid programmers. See, now I’m laying blame directly at our own feet. Programmers aren’t omniscient either. When you ask them to design a system they will make mistakes. The bigger the system the more mistakes. And most of these mistakes will only show up once you’ve built the system, meaning you have to change the system and we didn’t want to do that. Of course there’s an easy solution for this. You don’t let developers design the system anymore. You’ve got architects for that, they’re easy to find, they live in ivory towers.

So now you’ve spent a year creating the best requirements. Your architects have created a bulletproof design, you can now safely build your system right? Well no. Now you’ve got the real world to contend with. And it changes too.

I think we can safely conclude that resisting change isn’t a solution for our problems. Agile methodologies acknowledge that fact. Agile tells us to embrace change. But how do we make sure our software doesn’t make us regret this? We need to architect our software to embrace change too. Instead of going to around the problem like we used to do we need to get to the bottom of it and eliminate it from our software.

But how do you architect software to be changeable? Well this is another counterintuitive aspect of software engineering. In other engineering practices we have to contend with natural laws that constrain what we do. In structural engineering gravity is a big constraint. When you want to be flexible you build bigger foundations. In electrical engineering Ohm’s law is a constraint, so when you want to be flexible there you build in bigger cooling fins and more powerful power supplies. Software engineering is different in this aspect. Our main concern is complexity so preparing for change by over dimensioning your foundations will only work against you, you’re only making your software more complex, that will not help you fight complexity.

An agile architect will always go for simplicity. Do the simplest thing that will actually work, don't build things you’re not sure you’ll need. Keep responsibilities separated and abstract away everything.

A good old fashioned flame war

Mendelt — Wed, 17 Jun 2009 20:50:00 +0200

In the good old days of dial up connections and Usenet I used to enjoy a good flame war now and then. I’m not really a flame war kind of guy. I get distracted far too easy to really commit myself to consistently flaming my enemies. And I’m bad at remembering names so in an online-world where you don’t see faces I usually forget who I’m supposed to flame anyway. But other people’s flame wars can be really entertaining.

But it seems people are slowly adapting to the way they interact online. Modern media are great for flaming but somehow I see less and less of that. You still see occasional blogosphere drama and occasionally fanboy X bashes platform Y. But that’s about it. Most people have found out that the best way to deal with trolls is to ignore them. And so people seem to find middle ground far easier. Like they should … in most cases.

People seem more and more inclined to compromise. And usually this is a good thing. Most discussions end when people agree that both points of view have their merit. Apple vs. Microsoft? Both have their sweet spot. Scrum vs. Kanban? Same there, althoug both sides seem to think their sweet spot is bigger. I’ve seen people discuss Agile vs. Waterfall and come to the conclusion that both have their place… what? wait a minute? …Waterfall? …Really?

I want to take stand right here. I never saw waterfall work! ever!

What I did see were teams that claimed to do waterfall but where actually iterating and changing requirements on the spot. Not because they didn’t want to do waterfall but because it didn’t fit their way of working. Usually this meant that after every ‘phase’ most of the documentation created was filed away and when people actually got to implementation the developers did whatever had to be done to get the job done, instead of following the outdated design.

Sometimes teams of exceptionally good developers did succeed. Not because of waterfall but in spite of it. The reason they got work done was usually because they did something resembling agile when they finally got to writing code. But without the practices to support evolving and changing requirements like TDD and fixed iteration lengths this is very hard to do.

Most of the time developers weren’t that good, quality went downhill as they tried to evolve the code and eventually the project was cancelled.

I’m prepared to seek a middle ground on many subjects but when I hear something I know is wrong expect to see flames.

Where’s my MVC nested Master Page?

Mendelt — Wed, 17 Jun 2009 19:50:02 +0200

The first thing I actually missed from Webforms are nested masterpages. Fortunately they’re not missing at all, they just figured out those MVC guys (and galls) like code so much, they don’t need no stinkin’ templates for something as trivial as this. And of course we don’t. Here’s how to roll your own.

Masterpages are a great way to keep your webpages DRY. Repeating layout/markup/header stuff goes into the masterpage. This is great until you create a bigger site with more than one masterpage. Suddenly you’re repeating code between masterpages. So we go up one more level. We make a masterpage for the masterpages. Yes it’s tortoises all the way down.

We start with two normal masterpages. Master.Master and Child.Master. I’ve always been good in coming up with original names. They’ll both look a bit like this:

   1: <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

2:

   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

4:

   5: <html xmlns="http://www.w3.org/1999/xhtml" >

   6: <head runat="server">

   7:     <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

   8: </head>

   9: <body>

  10:     <div>

  11:         <asp:ContentPlaceHolder ID="MainContent" runat="server" />

  12:     </div>

  13: </body>

  14: </html>

Now we want Master.Master to look exactly like this. And we want Child.Master to look exactly like this but add “Child – “ before the title and we want the content of the child in VERY BIG LETTERS, so we’ll put a <h1> </h1> tag pair around the ‘MainContent’ contentplaceholder. I wanted to use <blink>, my favorite tag but it’s not supported anymore.

Of course we can just add all this to Child.Master and be done with it but we want to re-use the Master.Master code. So lets use Master.Master as a masterpage. This works just the way you’d expect. You just add a ‘MasterPageFile’ attribute to the Master tag and use ‘asp:Content’ tags to fill in the contentplaceholders. The big difference with content-pages is that you nest asp:ContentPlaceHolder tags inside the content. These can be filled in later by your pages. This is how your Child.Master will look.

   1: <%@ Master MasterPageFile="~/Views/Shared/Master.Master" Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

2:

   3: <asp:Content ID="TitleContent" ContentPlaceHolderID="MainContent" runat="server">

   4:     Child - <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server" />

   5: </asp:content>

6:

   7: <asp:Content ID="MainContent" ContentPlaceHolderID="MainContent" runat="server">

   8:     <h1>

   9:         <asp:ContentPlaceHolder ID="MainContent" runat="server" />

  10:     </h1>

  11: </asp:content>

Have fun!

ASP.Net MVC … Wow!

Mendelt — Mon, 15 Jun 2009 22:39:41 +0200

I’ve been very happy on the windows programming side. I used to do web-programming but frankly ASP.Net webforms spoiled that for me. Agreed… it’s very good for quickly setting up administrative websites that run inside the firewall. It has all the right abstractions for that allowing you to quickly piece together CRUD stuff without worrying about state, postbacks, javascript or even HTML. But when you want to build fun websites that look good and are designed to run on the big bad web these abstractions start to work against you.

Lately I’ve been getting a bit restless though. I needed to learn some new stuff. Frankly my job is boring, they’ve got me maintaining and supporting some C++ MFC application *yawn* so time to get back into web programming. Enter MVC!

Agreed, this is nothing new. Every other platform has had it’s web MVC framework for ages, even .Net has had monorail. But for me it’s new. And completely cool!

The architecture

I’ve been working with all kinds of UI patterns on the windows side. MVP, MVC, MVVM and so on hold no secrets for me but the web variant of MVC is a bit different for me. The whole routing thing took some getting used to, the controllers/view interaction is very simple compared to the windows world and I had to do some reading to get an IoC container working. But other than that the programming model is beautiful. No complicated page lifecycles but still every bit as extendable as we’re used to.

Testability

In webforms I had a whole bag of tricks to make things testable. Eventually I got some sort of MVP model working where I abstracted away all the page logic to a presenter object that was running behind the page. But the way pages behaved with controls throwing events all over the place this wasn’t as easy as it should have been. You had to be very keen on testing to go this route. In MVC things are the other way around. You have to try very hard to put logic in your views, although I have seen people manage this. Controllers are testable by default and everything is mockable. Great stuff for a TDD junkie like me.

Control

In webforms I had all but given up on javascript. The controls you put on the page had their own idea about what javascript should run and you had to fight with these to ajaxify your pages. In MVC you have much more control over how your pages look in HTML. This also makes it very easy to add javascript. I’ve even ordered my first jQuery book.

What am I building?

Wouldn’t you like to know? Right now the project I’m working on is still in the proof of concept phase. I’m trying to get some basic functionality working. If I’m more sure about the possibilities I’ll put a first version online. But that probably won’t be until the end of this year. But you can expect a lot of MVC posts from me in the future.

Looking back at Open Space

Mendelt — Sun, 14 Jun 2009 12:45:07 +0200

Last weekend I helped organize the Dutch Open Space Code Day. This wasn’t the first open space event I’ve been to but it was the first one where I was involved in the organization. Kees Dijk and me got the idea from the UK Open Space Code days that are organized by Alan Dean. And with some help from Imtech ICT, who kindly provided space, coffee and lunch, we got going.

So what did we do all day?

After a short introduction we started the planning phase. This is typical of open space, there are no scheduled speakers, all the scheduling is done at the start of the first day. Attendees propose sessions themselves, everyone votes to see what sessions are most popular. Then sessions are shuffled around to fit the available time and space. The schedule stays fluid for the rest of the event but most of the planning is done right at the start.

I can imagine this is a nervous moment for most open space organizers. What if no-one wants to propose a session? We had nothing to worry about in this respect. Many of the attendees were accomplished speakers on other conferences and I was confident they would also step up here. I wasn’t disappointed. On the right is what the schedule looked like after a couple of minutes proposing sessions.

After the sessions were voted on, combined and thinned out a bit we got going. Subjects ranged from Silverlight to DDD and design by contract, all interesting stuff. The first round of sessions started a bit late. So after only an hour it was already lunch time.

Most people just ate lunch while continuing the morning sessions. We had plenty of time planned for lunch so after about an hour people started coming back to the main room to get some coffee and get ready for another round of sessions. The afternoon round of sessions went by just as fast as the morning sessions.

On the whole I can say the day was a success. I had some worries that there were too many high-profile speakers attending and that this would kill the interactive nature of open-space but this just didn’t seem to be a problem. A couple of things could go better. People didn’t really seem inclined to move from session to session. Normally this is a mechanism in open space that ensures attendees get the most out of the sessions and sessions that are less interesting die out. In this case the quality of content in all the sessions was very high so there wasn’t much need for people to move between sessions.

The focus of Open Space Code is supposed to be on coding. This never got off the ground. Most people had laptops and some code examples were shown but at the end of the day no code was checked in to the Google Code repository that was provided for this day. This probably had to do with the fact that people had to specifically ask to get access to the repository. Next time we’ll try to streamline this process by providing access to a version control system beforehand. This way people can prepare code samples before the event.

I also got some suggestions to make the sessions a bit shorter next year. This time we had two sessions of two hours each to give people enough time to actually do some coding. Next time we’ll probably do three 1,5 sessions instead. This might fit in better with lunch too.

All in all the day was a big success. I’m really looking forward to my next open space event.

Pomodoro

Mendelt — Sat, 30 May 2009 19:04:00 +0200

I finally gave up and went with the hype. I admit it, I bought my first piece of Apple hardware. It wasn’t even as expensive as I thought it would be and its shiny. I always had a soft spot for brushed stainless steel.

Here it is, my first piece of Apple hardware.

So why am I blogging about a kitchen utensil you might ask? Well, actually this fruity piece of stainless steel is a productivity enhancer. Let me explain.

Focusing your work is often hard. And many tasks, like programming, need focus. Lots has been written about how interruptions from telephones, coworkers or managers will ruin productivity. But there’s a dirty little secret here. Even when you leave them alone most programmers are perfectly capable of interrupting their own work. They read blogs, have a chat at the coffee machine or read email. Having some time to wind down between work is of course good but but only when you’re able to do focused work in between those distractions.

Part of the problem is that our expectations about ourselves are too high. We expect ourselves to be able to do hours and hours of work. In exceptional circumstances this is possible, when you get into the mythical state of ‘flow’ time just flies by and todo-lists shrink at an alarming rate. But in most circumstances you need short periods to rest your mind in between work. The trick is to keep those rest-periods short and to really focus during work.

Enter the pomodoro. Or in my case a stainless steel apple-timer.

The idea comes from Francesco Cirillo who had the same problem us programmers have when studying. Days of study would fly by but when he looked back at what he accomplished during those study he was usually underwhelmed. In order to improve matters he used a tomato shaped kitchen-timer to keep an eye on time. He lives in Italy where a tomato is called a pomodoro and so the pomodoro technique was born.

Francesco realized he needed to do things to be able to focus, time his work-periods and rest-periods and write them down to be able to see if he improved. The technique is actually really simple, just simple enough to work.

The first thing is to achieve focus. You can do this by splitting up your time into periods of focussed work with rest-periods in between. The pomodoro technique uses 25 minute work-periods with 5 minute rest-stops in between. After 4 of these you get a longer rest-period.

To make sure you know what you need to do in these periods you need to keep a couple of simple lists. First you need to make a to-do list of the tasks you plan to do during the day. Just write down several tasks on a piece of paper. Set your timer to 25 minutes and start working. When the timer rings you mark a successful pomodoro and take a 5 minute break, you can talk to a colleague go to the bathroom.

The real trick is dealing with interruptions. Normally this is the hard part. Most interruptions can’t be delayed indefinitely. But because your pomodoro is only 25 minutes long you can often delay interruptions till the next break. Write it down, mark an interruption and continue the pomodoro.

If you want to know more about this check out these resources

Also available on …

Mendelt — Sat, 02 May 2009 22:51:44 +0200

Last week while I was on vacation and out of reach of any internet-connection my first article on www.agilesoftwaredevelopment.com was published. I’m pretty proud Artem, the owner of the site, asked me to contribute. It’s a great opportunity to learn from and give back to the great community Artem gathered around this site.

I’ll be posting an article there every two weeks, of course that doesn’t mean I won’t still be posting here. My blog-posts here will be mainly focussed on tech and .Net programming while my articles on www.agilesoftwaredevelopment.com will be focussed on .. well .. agile software development. I’m writing agile with a lower-case ‘a’ here on purpose. I’m not a manager but a software engineer, I’ll be writing about agile from an engineering perspective, and of course occasionally about the management aspects of agile when I think managers get it wrong. I like to think engineers are more down to earth than managers and don’t need upper-case buzzwords.

So everyone please come visit me on www.agilesoftwaredevelopment.com when you’re interested in my agile ramblings and visit me here for the down to earth tech stuff!

Looking for an IoC container in several wrong places

Mendelt — Tue, 21 Apr 2009 00:02:56 +0200

I’ve been using Castle Windsor for some time now. The way I use it is probably non-standard and that’s why its proving quite hard to find an alternative for it. So I decided to download a a nice selection from Scott Hanselmans listof IoC containers and give them a go.

First let me explain why I’m looking for an alternative when Castle Windsor is clearly one of the most used and most capable IoC containers out there. Its actually quite simple. The last official Castle release was in 2007 and that was only a release candidate for version 1.0. An official version 1 has never been released. For me personally that’s no problem. The project is still being worked on, new features are being added and its easy to pick up the latest version from the SVN trunk, build it and use it. There are even new releases planned. But its a hard sell to use it in commercial projects. I need something that’s mature and visibly supported. Shouldn’t be too hard right?

There is one feature I would like to have in my new IoC container and that’s the IInitializable or something that can take it’s place. Let me explain.

Most getting-started guides on dependency injection and IoC the first thing they show you is how to do constructor injection. Constructor injection is very powerful because your component is never half-initialized. It always has all its dependencies set. But I like property injection better, for the simple reason that property injection gives me more flexible code. Changing around dependencies is easier because I don’t have to rewrite all the tests where I still call constructors explicitly. In order to still be able to do some initialization after all dependencies are set in my component I made extensive use of Castle’s IInitializable. This is an interface that specifies one method: Initialize() and Castle guaranteed it to be called after the components dependencies were set.

So the search begins:

But first a disclaimer. I’m not claiming one IoC container is better than another, I’m just looking for an IoC container to support one non-standard usage scenario.

Unity

This is where I started looking. Unity is a Microsoft product. Its supported by the Patterns and Practices team so support is more or less guaranteed (unless they pull a “Linq to SQL” and drop it in favor of its bigger brother, MEF) It should be an easy sell. Unfortunately its not really mature yet and for instance doesn’t support my initialization scenario.

Spring.Net

Spring.Net actually gave me the biggest surprise. It works quite differently from what I’ve come to expect of IoC containers. Instead of mapping Interface-types to classes it maps string-keys to classes. Auto-wiring is harder this way. In most cases you have to explicitly specify dependencies between components. No go there. And that’s unfortunate because it seems Spring.Net has the best support for my initialization scenario I’ve seen yet. No need for interfaces. Spring.Net just calls Start() on any component that has that method. This is a nice example of convention over configuration.

Autofac

Ah, thats more like it. Autofac supports my initialization scenario. Not in one but in two ways. You can specify an OnActivating eventhandler when registering a component or you can use the Autofac.Contrib.Startable module. Neither way is as clean as Spring.Net’s Start() method or even Castle’s IInitializable. But they will do. Autofac.Contrib.Startable is not ideal because it forces you to start all components at registration time, normally components are initialized lazilly when they are needed. The eventhandler scenario forces you to write eventhandlers to call the startup-routines.

Other than that Autofac seems to be just what I need. It has a nice and simple ‘DSL’ for configuring the contianer. It doesn’t have all the bells and whistles Castle has but it has bells and whistles I might actually use like ASP.Net MVC integration.

Structuremap

Last but not least is StructureMap. StructureMap and Autofac are on par when it comes to features. StructureMaps DSL for configuring the container is a bit more extensive. For me this is a good thing. Configuring setup of components can be done with a lambda expression, this is a bit easier than the event-handlers used with Autofac. But other than that the DSL seems a bit contrived in places.

I’ll probably try both Structuremap and Autofac for a while. All IoC containers have similar features and differences are quite subtle. Right now I lean towards Autofac for it’s simpler configuration although Structuremap seems to support the one usage-scenario I thought up a bit better.