I’m surrounded by brilliant minds at work. Both at my company (Aptitud), at my clients and in my community. They make me think a lot and quite clearly thinks a lot themselves too.

But sometimes I think we think too much (cannot wait for the reaction to that contradictive sentence :)) - and we should do things instead. It’s in doing we learn and see how stuff work out and how well our hypothesis stands up to the reality that we throw them into.

Let me give you a few … well examples and ideas that have formed my thinking around this.

Getting to know new people

| | |:————————————————————————————:| | | | From http://redstarresume.wordpress.com |

I have never been in a situation to hire someone - although I have done A LOT (50+) prospect...

In my last post, I shared two stories that got me thinking about what we code for: change or stability.

The post received unexpected attention, prompting questions that led me to reflect further. Here are some thoughts and answers to recent discussions:

Mindset vs Practice

My initial post didn’t emphasize the mindset aspect. Coding for change means anticipating future modifications and making them easy. It shifts how we approach coding, focusing on simplicity and adaptability.

Consider a thought experiment: imposing a constraint to rewrite code every few months. How would this change design, coding, testing, and documentation practices? While impractical, it prompts valuable reflections on code flexibility.

“WHAT WAS CHANGED IN THE GAME SPECIFICATION???”

A question from Reddit referred to a game development scenario where we introduced a new player feature. We adapted our code to accommodate this unexpected change, leveraging existing infrastructure and generic constructs.

Let me tell you a story: when I was in university I took an “advanced” object oriented programming course. This was my first exposure to the topic and I was lost big time. The course was taught in SmallTalk had a very different format; the first day we got an assignment from the professor that ran throughout the 4 week course.

We were very excited since we were going to write a game. An old-school text-input adventure game a la Zork. We teamed up three people in groups and went to the professor smalled crammed room. Here we got the instructions on a single sheet of paper. We almost ran out of there.

Just as we reached the door of the room he called us back (I’m sure he had time that call to perfection):

“Oh yeah, almost forgot. Two weeks from now I will come by and change...

SpecFlow is a wonderful tool. With a lot of hidden gems inside of it. I have been using and coding on it now for about 4 years and still I often forget about features and extension points that Gaspar and the community has put in there.

For example: did you know that there’s an inversion of control framework built right into SpecFlow? Now you do and in this post I wanted to show you one way that you could use that feature to make your step definitions more maintainable.

I found this feature (again, I had heard about it before) when Gaspar mentioned it too me after my presentation at CukeUp 2013 and the usage is part of “Pushing the HOW down” which I wrote at length on before.

The Context injection feature (as it’s called in SpecFlow) is one of those “just works”-feature and...

I’ve just attended my first ever CukeUp conference, that is given by Skillsmatter each year. It’s organized by Aslak Hellesoy that created Cucumber five years ago. It attracts a nice audience and community that share a lot of interest with me. For me it was extra fun to meet some of my heros and friends that I’ve followed and interacted with for quite some time (Matt Wynne and Gaspar Nagy to mention a few).

As always at conferences the learning is plentiful, even though my focus and nervousness was at my talk for a few hours. I especially like Matt Wynnes talk on Cucumber Pro Tips. There’s two excellent books (The Cucumber Book and Cucumber recipes) that Matt and friends has written that contains loads of tips and pragmatic hands-on descriptions for any Cucumber user. His talk was an extract from...

I’m coaching in an organization new to agile practices. This challenges my assumptions, like explaining practices I’ve taken for granted. Recently, a dialogue unfolded:

Me: You’re doing a lot at once here… Product Owner: Yes, but we’ve promised to finish a lot by [date]. Me: Why not limit your work in process (WIP)? It speeds things up… PO: What do you mean? We can’t limit work. We must complete this [pointing to board] now, as fast as we can.

I realized I missed explaining WIP (work in process) and why stakeholders aren’t concerned about it.

First, what’s a WIP limit? It’s a team agreement on how much work to take on at once. It’s flexible and guides our work to flow smoothly.

In Scrum, teams commit to work for a sprint, ensuring balance and commitment. WIP limits serve the same purpose—controlling how much work to take on at once....

I’m working for Tradera right now and as I’ve blogged about before we have been splitting a big (40 people) team into smaller ones. Getting this to continue to work and the teams to be effective has been my challenging and very interesting task since then.

I can tell you that without great people that care - this would have been a lot harder. With people that care, you can even allow yourselves to try something, fail, and change. That’s great news for someone like me - I fail a lot. And take great pride in doing so, as long as I learn from it.

In this post, I thought I’ll describe a particular part of that process that I have had problems getting to work many times; the daily team sync, Scrum of Scrum, or Syncro whatever you call it. We call it Daily Sync.

The problem

I have been playing around a bit with MongoDB for the first time of my life. It’s really a very nice experience and have a lot of the “just works”-feeling that I have started to get used to from frameworks like NancyFx and Simple.Data.

But when I pushed it to AppHarbor I ran into problems. That all had with me not reading stuff properly…

AppHarbor has a nice feature that replaces stuff in your .config files on deploy. That could be used for setting Production-environment values to your environment configuration. For example changing the connection string for a database.

The add-on for Mongo DB at AppHarbor has a nice article describing this in detail. But I read it quickly and put the connection string in the -node of the web.config.

It should be added as an . As the documentation clearly points out. So you want this:

...

I’ve built a small application. Just something I threw together with a friend during a hack-session at the client. (It’s a dot voting application and you can try it here, if it’s up :))

As we wanted something out there fast we built it with NancyFx and MongoDB (a first for me) and we host it on AppHarbor with continuous delivery via GitHub. Since all of these (saved Mongo) has served me well in the past I was very surprised when we ran into problem.

When a commit is pushed to AppHarbor the application is compiled and the test (if any) are run. That worked fine for us but then a stage is run that’s called “Site precompilation”.

That failed with the following error:

error ASPCONFIG: Could not load file or assembly ‘Nancy.ViewEngines.Razor.BuildProviders’ or one of its dependencies. The system cannot...

At my current client, we have split our teams into five smaller (8 people) teams. I wrote about that process before, if you want to read about that. One of the big concerns that people have had after the split is how we make sure that we don’t miss stuff that “falls between the chairs” for these teams. I think that’s an overstated problem, but we sat down together and, as always with great people that care, a good solution came out. This post shows our findings, and I’ll try to unfold my thinking on why I thought the problem is overstated as well. Since we’re now brushing on business-critical strategies, I need to keep this post fairly general. I’ll try my best to make it understandable.

The Problem

My client now has five different teams that have separate backlogs and work towards realizing strategically important initiatives...