Are you coding for change or stability - the followup post

· April 24, 2013

In my last post I related two stories that I’ve been a part of and that got me thinking about what we (or me at least) code for: change or stability.

The post got attention (amazing attention for a small time blogger like me, actually almost afraid of writing now :S) and quite a lot of questions was posed. These of course got me thinking even more and I realized that I needed to follow up on the post. So here it is: some thoughts (and some answers) to questions and arguments I’ve had during the last week.

Mindset vs practice

What I bluntly failed to convey in the first post was the mindset aspect of it all. For me the difference in approaches was one of mindset in what we develop; do we write the code thinking that it will change or that this is the last time we ever touch or see it?

For me this completely change the way I approach not only writing the code but also thinking about the problem. If I take on the mindset that this will be changed I would try to make change easy (more on that later) and I might to do the smallest thing possible to get something out there and learn from that.

Maybe it isn’t me changing this code the next time - how can I make it super-easy for the next developer to understand what I was thinking, so that she can make the change easier.

A interesting thought experiment (or do you dare do this in practice?) is to take on a constraint that you will start rewriting your code base after a certain number of months. No code, in this module, will live longer than 3 months, for example. What would that do to the way you approach the design? The coding? The testing? The documentation?

Yes, yes… that’s probably impossible for most of us. But use it as a thought. What would happen? What would we gain from that? What would we loose from that?


This was one of the questions I got asked on Reddit and it’s a fair one. If you remember from the last post our professor gave us a programing task to build a game, and then told us that he was going to change something in the specification after a couple of weeks.

For my team (3 people; Magnus, Mats and me) the change was to introduce a new player. An computer controlled player that mimicked your every move but 3 turns after you. We called him “the mimic monkey” (Härmapan in Swedish).  

There we’re other changes as well; adding graphical interfaces, changing the language that you used to instruct the person, being able to script the player etc.

The concept was one that we never had thought of when we started to create the game and it took us some time to think about how to introduce that into the game. When we coded it, if my mind serves me right, it took us about a day or two.  

The change was easier since we had created a lot of infrastructure and generic constructs to support additions and changes. MOST of them was never used…. Some proved useful for the particular change at hand.

Generic vs simple

And that brings us to my final point. This was one of my first exposures to object oriented programming. We had just learned about design patterns and used them all over. We built our code to be as generic as possible, for every line (or well… method at least) we thought things like:

  • maybe this will be changed?
  • We can break this out to a base class.
  • If this is a interface we can swap the implementation
  • Couldn’t this be read from a file…

You see where I’m going. Most of these things were never used of course, during the short course that we took. If the project had gone on for several year, more things that we built into the first generic and flexible design maybe had been.

It is summed up in this excellent XKCD cartoon:

I've changed. I now much rather preferred something small, simple and hardcoded over a generic flexible solution. I've come to realized that the added complexity does seldom get used. It doesn't mean that I'm throwing everything I know overboard, but I use the tools only when they helps me write stuff simple. I strive to write simple rather than flexible code. For me changing simple stuff is faster than changing stuff that was written with flexibility in mind. I love the ideas behind [micro-service-architectures](,d.bGE) that a lot of people talks about these days. That is: super small (often nothing bigger than classes) service that talk to each other in a uniform way. Yes - that creates a lot of services, but it's still simple to grasp since you don't have to take them all in, all of the time. You just have to concern yourself with this little service and the once that it use. You can even allow yourself to duplicate stuff if needed (not to absurdum of course). If one of the services is cumbersome to understand and handle; let's rewrite it. Let's split it up into 5 smaller ones. All of this is simple and fast since the service are small. ### Conclusion That's coding for change for me. In the [Agile Manifesto]( we read: "Responding to change over following a plan" and one of the [principles]( states: "Simplicity--the art of maximizing the amount of work not done--is essential." That's why I love frameworks like [NancyFx]( ([Sinatra]( on .NET) and [Simple.Data]( that helps me write super small services in a few, easy to read and understand lines like these: This little service get all the users with a given name and returns it to the caller in the format requests (look into [Nancy content negotiation]( for more on that). Simple. Tiny. Easy to change. Oh yeah - a final word: I sure hope that I change my mind about all of this. Often. It would be super scary to think that I would know it all now. Brrrr. Code for change. Change will come. Change is good.

Twitter, Facebook