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?
“WHAT WAS CHANGED IN THE GAME SPECIFICATION???”
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:
