Skip to main content


Showing posts from 2009

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?

Agile architecture, embrace change by reducing complexity

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.

Using a nested Master Page with ASP.Net

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.

ASP.Net MVC … Wow!

I’ve been very happy on the windows programming side. I used to do web-programming but frankly ASP.Net web forms ruined 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 allowing you to quickly piece together simple grid-based CRUD webapps 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 need to learn some new stuff. Frankly my job is boring, right now I’m responsible for maintenance and support for a legacy C++ MFC system *yawn* so time to get back into web programming. Enter MVC!

Looking back at Open Space

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.


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.

Agile maturity

In the ten years I’ve been programming I’ve learned two pretty important things. Project success is about people and teams. No matter your process, good teams will succeed (usually in spite of your process) and bad teams will fail. Every time you make a rule about something, people will stop thinking about that thing and blindly apply the rule. This sounds pretty bland, even Chinese fortune cookies usually have more interesting things to say, until you think about one of the consequences. You need good people for project success but if you give them too much rules they will stop thinking and become as smart, or as stupid as the rules. Most Methodologies seem to think that more rules is better. If a rule doesn’t benefit you it surely won’t hurt too much, just implement as much as you can and things will surely get better.

Not all quality is free. But it’s cheaper than you think

I started writing a reply to this post but it got kind of long, by the time I started thinking about adding pictures it dawned on me that it’s probably a good idea to write my own post on the subject. The discussion here is based on an idea from lean development. Traditionally people thought that quality had a price. Removing defects has a cost so more quality means higher cost. Lean production tells us this is not true. If you remove the defects sooner you can remove them cheaper. By removing the cause of the defects you can prevent them from being added. This will not only improve the quality but actually remove the cost of fixing the defects. Agile methodologies like XP show us that this works for software too. Up to a point.

Chaos in WPF

I’ve been reading up on math lately. Mostly chaos theory and nonlinear dynamics. I still don’t get why they don’t teach stuff like this in school, I might have even found math fun if they had done so, part of the fun of these areas of mathematics are the cool graphics they produce. Everyone knows the Mandelbrot set, but in this post I want to focus more on chaos theory. And to make it interesting for my usual readers lets draw some pictures with WPF

I can’t go to bed right now

Someone is wrong on the internet. In the past few episodes of the stackoverflow podcast Joel Spolsky and Jeff Atwood already talked about SOLID principles and TDD saying they don’t really care for it, they both seem to have been successful without it. They also admitted neither of them had any real experience with this style of programming. This is why I find it really surprising Jeff even took the trouble of writing another blog post about this voicing his opinions about a set of principles he clearly has never practiced.

More about dependency injection

In a previous post I talked about problems caused by singletons and how to solve them using dependency injection. I mainly talked about constructor injection. In a reaction to that post Roy Tang voiced his concerns about scaling contructor injection. In real life applications you often have a lot of dependencies, passing them through constructors can become a problem in real life solutions where you’ve got objects with lots of dependencies. Usually when manual IoC does not scale anymore I use an IoC container. But this might not always be an option. In this post I want to talk about a few ways to get around this problem.

Fun with planets

Over the holidays I finally got around to doing some recreational coding again. The results even surprised me so I thought I’d share it with my blog-readers. So here it is, your very own planitarium. Planets flying around with real gravity just like Newton taught us (who needs all that fancy new-fangled relativity anyway), and if you feel like it you can even play God and slingshot planets into outer space. Just try clicking anywhere in or around the window.