Development for Fun

I said in a previous post that in my opinion, Agile brings back a certain amount of creativity to the developers that I felt had been lost in a corporate environment. I wanted to elaborate on this based on a concept that I would call “Development for Fun” (DFF).

Back in “Ye Goode Olde Days™” when I took my first steps with software development, most people who chose to learn programming did so in a learning-by-doing self-taught approach and pursued programming as a hobby before transitioning into a professional environment and turning their hobby into a job. Nowadays, it seems to be far more common that developers get their first development experiences in classes (e.g. in high school or at the university). They never experience what it is like to code for fun, but right from the start, they do software development in an environment where they are told what to do and how to do it. They rarely experience the creative freedom that comes with self-teaching and with writing software for ones own enjoyement based on ones own needs and requirements.

But what is so special about “Development for Fun”?

Well, ask anyone how they write software when they do this DFF. I think most people will give a description quite similar to this:

1. Come up with a rough plan.
2. Start coding
3. As soon as you have something that can compile, you compile it
4. Fix compilation issues immediately.
5. Test the resulting software
6. Fix functional bugs immediately
7. Adjust your plan, if needed
8. Write another few lines of code, and go back to step 3

This loop between steps 3 and 8 is usually extremely tight in DFF. Often, you just implement one new function or one new method. In some cases, you might write only a single line of code before going back and checking how it affects your software.

Looks familiar?

This is the probe/sense/respond cycle that the Cynefin framework suggests for complex problems.

So when doing DFF, developers intuitively understand that when you are dealing with a complex problem, it is best to check back very often whether you are on the right path to fix problems and to adjust the planning. It is obvious common sense.

Of course, also when you learn coding in a class, you can make this experience. If your teacher tells you to implement a sorting algorithm by the next day, there is nothing that would keep you from doing the implementation in a tight probe/sense/respond cycle. The main difference is that when doing DFF, you are also collaborating very closely with the customer. In fact, the customer is sitting on your chair, as you are the customer. Customer collaboration can’t get any closer than that. So you not only have the freedom to change a line of code here and there, but you can also get the go-ahead from your customer to change the direction of the whole project based on problems and opportunities you discover during your work.

This is why I believe that DFF is a kind of basic model for agile software development. The only difference is that Agile approaches add rules to this model to make it compatible with working in a corporate environment, with working in a team and with working for an external customer. But the common sense core of DFF remains in Agile and is the key driver. And that is one of the great things about Agile: What was obviously undeniably common sense in DFF is not discarded in Agile but instead built upon. This is why I believe that Agile has the potential for also carrying over the creativity and fun from DFF into a for-profit development environment.

This is also something that developers need to understand. Agile is not supposed to be another management bullshit bingo term that will only create additional work and overhead for them. On the contrary – it is supposed to let them work in a way how they would most likely choose to work if they were given free reign.