Developing Better Software Faster by Being Slower

In the last few years, the slow movement has gained some popularity. We live in a frantic world. Everything needs to be done by yesterday. As a result we're becoming increasingly dehumanized. The movement aims to counter this.

Adopting this mindset has provided me some benefits during the last few years. I guess my first touch with slow, even though not conscious, had to do with exercise. Some years ago I decided to get fit. You've got one life (not three or more like for Mario) so why not to spend it while being fit? Besides, you might be around a bit longer.

I remember starting really slowly. I did something like one long and slow walk per week and then some shorter exercises (a bit of running even). It was important not to start too fast. By draining yourself physically early on, you'll lose the will to continue. It takes a while for the body to adapt to the new regimen. After you get around the initial hump, the benefits are just huge.

Since then I've discovered barefoot running shoes, road biking and skiing even. Just today I finished a 135 km tour, something I couldn't have even dreamed of doing a couple of years ago. During the last summer I finished my first "epic" biking trip (three days, from Oulu to Jyväskylä). I've never been fitter in my life.

So how does it show? I simply have more stamina, my muscles won't hurt anymore after exercise, I rest easier, I don't get really sick anymore, my feet have seemingly repaired themselves (flat arch before, normal now). Better yet, if I feel a bit weary, all I need to do is to go for a ride for a fresh dose of endorphin. Man, that stuff is powerful.

Software Development - Too Fast for Its Own Good

Okay, now that I got that out of the way and hopefully got the message through (being fit is cool) I can get back to the topic at hand. One of the main things I've learned from exercise is that you cannot simply go fast all the time. You will need to take it easy at times. Especially in exercise regimen it is important to vary the type of exercise you perform, otherwise your body just adapts to the exercise a bit too well and you won't gain the benefits as well as you could. Sometimes you might need to push it a bit or do something different altogether.

Consider a typical software project. Commonly it's a frantic race against the clock. Longer term this is just draining, both mentally and physically. Worse, it's likely you won't have time to codify the things you've learned. Instead you might have to resort to hacks again and again just to beat the clock. Dave Moran actually discussed the disadvantages of developing this way a while ago. The core point is that by going too fast you might lead a more disciplined team for a while but long term you'll lose. This reminds me of marathon and the dreaded wall.

Can we provide better software, faster? I believe that yes, we can (to quote Obama). Software, and quality, are fractal, scale-free, by definition. It has certain kind of self-similarity. The structures are more or less similar on each level. By spending time and effort to make sure we don't build the wrong thing the wrong way this turns to our advantage. We'll be able to retain our cadence while providing the customer value continuously.

One problem that constantly faces us in the field of software development has to do with the nature of information. Either we know it or we don't. We also might have some idea of what we don't know. But most importantly we don't know what we don't know. This category is also known as unknown unknowns (thanks Rumsfeld!).

This is actually the reason why the first version most likely sucks. The second will suck a bit less and the third will be better even. It is extremely hard to get everything right the first time. We can improve our first guess somewhat, though.

The Answer

I believe the answer to this problem has to do with the speed of development. We'll end up better of if we have patience to understand what the users are after. This sort of lean approach to UX provides us means to provide better results faster. Going slow doesn't necessarily mean we cannot go fast long term. Software development isn't just a series of sprints, it's a marathon.

I'm not saying that lean UX is the answer to everything. It's not. It still takes a lot of craftsmanship and experimentation even to figure out nice ways to solve actual problems. Every person working on a project has to take responsibility for its quality. This responsibility implies ownership. You aren't building just something for someone to get some bucks, you are doing it for a good reason.

Just treating the user as a black box won't do. Usage of personas can help quite a bit. Instead of trying to imagine what the generic user wants (or rather the customer) we'll have a better way to justify our decisions. What would Joe the plumber do? What motivates Joe to use this accounting software?

Conclusion

I certainly hope lean UX and related approaches become more popular amongst software developers around the world. We have to take pride in what we do. Programming isn't just a job amongst others, it's a passion. By tweaking our approach, we can perhaps provide better service for our clients.

AgileJkl - Birth of a Community

Who would have thought Jyväskylä would be the place to be in the 2010's? It seems there are a lot of interesting things going on around here right now. I guess the revitalization of the local scene started around a year ago as we began to arrange Geek Collision meetings. It's amazing how much good a few beers (or ginger ales) once per a few weeks can do. AgileJkl was one direct result of that. Furthermore we've had technical talks and that sort of fun.

In this post I'll go through some highlights of the event. It was doubly nerve-wracking for me as besides being an assistant we performed a field test on our QR related product. Overall the event was just great and the test went fine too. I couldn't have asked for more.

AgileJkl - What Is It?

Agora Lobby, courtesy of Daniel Schildt

AgileJkl brought together a wide range of people interested in agile development. It managed to attract somewhere between two and three hundred people. Not bad for a first time, eh?

The conference focused primarily on the business side of agile. As a technical person I might have appreciated more technical talks but perhaps we can get a track for that done next year. Nevertheless the talks were interesting and well executed.

Especially the last talk about customer development by Marko Taipale hit the spot. It's just these type of things I've been struggling with lately. Now I have a better idea on how to proceed.

I won't go into detail about the talks as there is some commentary on that already. Besides at times I was distracted by some development duties. We did some on-site development on our product. Talk about being agile and responding to the demand!

It is difficult to say for certain but I believe this event will go into history as the birth of agile community in Jyväskylä region. We already have a small developer oriented community here as mentioned earlier. It would benefit from infusion of more business oriented people, though. Perhaps this will lead into that direction. We'll see.

bongaus.fi - Some Thoughts on the Experiment

Scanning QR, courtesy of Daniel Schildt

We've been developing bongaus.fi on and off starting from the beginning of March. We wrote the first prototype in two days or so and gave it a go at the Instanssi festival. The next trial was performed at Jyväskylä Design Week around a week later. This time we did a little pivot and gave the concept a go in a different kind of context.

I know this type of development goes against all the conventional theories. You are supposed to plan first, get some funding and then start doing the thing and hope it works out. We did literally the opposite. This is actually something Marko Taipale discussed about in his talk. It's better to test the water early than to hope the thing floats once its done entirely.

It was really exciting to see people using our service. Surprisingly many had genuine interest towards the system. This bodes well for future development.

Conclusion

It is extremely nice to see what people can achieve together if they put their mind into it. I know from experience that organizing events, no matter how big or small, always takes a lot of effort. Thank you for that and accepting our humble little service as a part of the show! I hope we can make the event even better next year.

I snatched the photos from the collection of Daniel Schildt. Thanks for the awesome photos Daniel!

The Language of Commitment

In this brief post I'm going to talk about the language of commitment. See, I did my first commitments there. I promised to keep this post brief. I also promised to explain this concept, language of commitment, to you.

This isn't something I invented myself. I actually came upon it around half a year ago while reading Uncle Bob's "The Clean Coder". The relevant chapter appears to be freely available even. I wasn't particularly impressed by the book but there were a few golden nuggets such as this that I picked up.

Since then I've observed it in practice. I thought it might be fun to share the concept given it's quite useful. You'll definitely have a different outlook on the world once you understand it.

Commitment - What Is It?

The language contains a lot of hidden clues about our intent. When you say you are going to do something "soon" what are you committing to? Contrast that with something like "I'll do that by tomorrow" and you get some idea of the strength of the commitment.

You can notice the same thing in a group environment. When someone says "we'll do that" who actually is meant to do something? That doesn't sound very committed, eh?

When you start to hear a lot of "soons" and "wes" you know you'll be in trouble, sooner or later. These things tend to pile up if no one takes responsibility of anything. You should take these kind of warning signs seriously.

How to Deal with Lack of Commitment?

Like in the case of illnesses you want to cure the underlying problem, not just to treat its manifestation. What causes a lack of commitment?

Lack of direction. If you don't know where you are going you aren't likely to get there. You'll need to have some concrete goal in mind. Realistic deadlines combined with a clear vision of the intended state are one way.

It is also possible that you are committing into something too abstract. In order to commit properly, you'll need to chunk it up and estimate. This way you get something concrete that's easier to deal with. Now instead of saying "soon" you can say "I'll get this part done on Monday" and so on.

In order to deal with the "we" problem, you'll need to assign and take responsibility. Again, the goals might be too abstract so chunk them up. This should give you a clearer idea of who should do what and when.

Conclusion

The next time you hear someone saying "soon" or "we" you'll know he probably isn't that committed. Instead of accepting this "as is", dig in and figure out what he is really saying. This might give you some surprising insight.