The Evaluation of My Software Sabbatical

Tuesday, 14 August 2012 - 23:43

Inspired by Stefan Sagmesiter, Rick Hickey and Richard Hamming, I decided to try a software sabbatical and devote one full month of unpaid leave to simply ponder on the wider puzzles of our software industry. Even though the practical results were meager, it gave me an opportunity to concretize some of my visions and I learned a lot about my own needs for creativity. This article will be a summary of this way too short journey, along with some thoughts on the process of innovation itself and what attitude we should have towards it.

First of all: one single month is a very short time to do anything at all. I started out with three simple projects in mind, and the general assumption was that since I had spent plenty of time pondering hazily about some general concept, this sabbatical would provide me a month to make them happen. I realized afterwards that this approach was somewhat misguided to the notion of using a sabbatical for creative thinking, since hammering down code doesn’t really require the same disruption from the everyday routine to be productive. Instead of spending a month with the aim of producing code, I should have focused completely on just creative thinking and leave the actual hacking to the evenings of rest of the year. Luckily for me, my initial ideas quickly turned out to be very abstract and vague when I actually sat down, so much of the month was actually spent on exploring new approaches anyway.

Most of the practical work during the sabbatical was spent on studying compiler technology, since that turned out to be the common denominator of my ideas anyway. I was hoping to produce some kind of measurable results, but in practice there wasn’t much done other than some prodding experimentation. This was of course was very valuable to me, but it didn’t really spawn anything to show off. This realization was kind of dejecting to face in the middle of my leave, but I also had to accept that it’s quite naive to expect one to cover what essentially is a five week university course during the whim of a few days.

On the positive side, I learned a lot about compiler technology (I really should have taken that course when I actually was studying at the university) and I feel essentially more confident about my ideas and how to proceed with them. I am also happy to mention that I’m currently working on a framework for modelling and transformation that I’m very enthusiastic about. I hope to use it in the future to demonstrate alternative programming principles that are more focused on actual problem solving rather than just telling a machine what to do. My visions of these principles are getting more solid, and I got some articles on the way that I genuinely believe will provide real value for people interested in improving the efficiency in their production environment.

Beyond the compiler studies, I also spent plenty of time pondering about the concepts of creativity and innovation itself. It was very refreshing to analyze my own experience very thoroughly and reflect upon what needs I have myself when it comes to creativity. Even though a month was a very short time it was rejunivating to just try the experience, and I learned a lot that will benefit me greatly the next time (yes, there will be a next time, as soon as circumstances allow it). Just to get something straight; the sabbatical is not a revolutionary recipe for all the world’s complexities, and there is certainly nothing magic about it. It is simply a different approach in the sense that it is aimed to find new ways to solve problems.

Simply speaking it is an attempt to be more innovative and creative. When you sit in front of your computer and try to fix bugs in your code, the solutions are often in the sum of the details in front of you. Leave that kind of thinking to the production environment and devote your time off to the more the abstract visioning. If you consider doing something like this yourself, I have a set of personal realizations I would recommend you to consider.

Incorporating creativity and innovation

The ambition is to find ways to incorporate the principles of innovation into the production environment of everyday office life. Preferably on all scales, from the small start-ups to the big machineries of big corporations. Obviously my experience is not mature enough to give any real pointers, but as I was given time to scrutinize my own experience I have some realization based on my own needs for creative situations.

First of all, you can’t make people innovate, you have to let people innovate. Innovation is dependent on creativity and inspiration, and people are creative at different times in different environments. As Rick Hickey states in Hammock-driven development when he talks about the background mind: you can only feed it, not direct it. Like a gardener, you can only provide the right conditions. You put the seeds in the soil, provide water and sunlight, then you guide the process along the way. You can’t pull the flowers from the ground, you have to let them grow. Sometimes they flourish, sometimes they die.

Brainstorming workshops

I think there’s many of us who have stumbled upon this approach once or twice in our careers. You arrive in the morning, and after some hyped power point presentation you get bumped into team A and assigned to solve problem X. You spend some hours disputing back and forth, you summarize it in a couple of notes, then you forget all about it while you stumble back to your bug fixes and code reviews. Some days/weeks later your manager posts an evaluation and people expect results to act upon.

The biggest problem I see with these problem solving workshops is that they are too focused on actually solving problems. There might be value in this if the problems aren’t too complex or significantly life changing, but to me this approach misses the key points of creativity completely. People look at the gathered notes at the end of the meeting and expect them to be the end results. These notes are not the results, they are barely the seeds. People have very individual and very specific needs when it comes to being creative (at least I have), and these meetings simply presupposes that those needs are synchronized at that specific location at that specific time. Personally I have never managed to contribute any substantial value from a meeting like that. Have you?

This is why I believe these brainstorming workshops where people are locked up in a meeting room are a bit misfire, even if they are done casually. You can’t just stick a bunch of people in a cabin somewhere, armed with a fixed list of issues, a whiteboard and a case of beer, and hope they will eventually reach the Balmer peak. Events like these are of course precious opportunities for collaboration, team building, getting people to reflect upon the problems and constraints, but in my experience people (including myself in former days) tend not to realize that this is only the first step. Once you crammed all the details in your head, you need the actual incubation time in your background mind, but people skip this part and run right back to the office treadmill.

Public conferences

In contrast to the brainstorming workshops, I believe the more generic conferences (I really enjoy the ACCU conferences) have so much great value because you actually get to meet people outside your own box. I have noticed that the attitudes towards these conferences are quite dispersed. Some people think they are awesome while others think they are just a waste of time, and I think most of the negative opinions come from misled expectations. In similarity with the brainstorming workshops, you shouldn’t consider the content to be the end-value. The seminars and presentations shouldn’t be considered to be instruction videos (although they often do contain very solid chunks of knowledge), they should be considered as diverse sources of inspiration.

To me the real value of these conferences is the opportunity to engage in discussions and debate issues with other people, some of them the oldest and most experienced gurus of the industry, others more young but from a completely different professional background than you. Maybe developers in the finance industry perceives some problems different than the developers from the media industry. Maybe developers from the small start-ups sees other difficulties than those faced in the big international conglomerates. Can they learn something from each other? Of course they can! Each evening at the hotel bar provides wonderful opportunities to exchange ideas with your fellow attendees. The fact that each conference day is packed with thoughtful conversation starters from morning to evening is for me just a bonus.

X% off for personal projects

The approach of giving employees a certain amount of time off for their own projects—hoping it will spur innovation and new product ideas—has been around for some decades now. Although it seems the concept was made famous by Google, the idea was apparently realized at 3M where Arthur Fry invented the Post-it note. Hewlett-Packard is also well-known for this approach.

The success stories certainly seems grand, but I must remain skeptical even though I see great potential in the approach. As I stated earlier, you can’t make people innovate, you have to let them, so just throwing free hours at people will probably not yield automatic miracles unless you have a very unique work environment. Scheduling time for these personal projects has also been shown to be difficult for social reasons when deadlines and release dates are closing in. I don’t have experience of this myself, but the consensus seems to be that it’s a good idea but hard to implement in practice.

Personally I believe a more healthy approach is to focus more on personal education and development of new skills rather than just cracking fun hobby projects. I noticed that Itemis, the main developers of xtext, adopts this principle with their 4+1 approach. It seems more down to earth since you will need skills and deliberate practice to grease the wheels of your current development anyway, regardless whether you are innovating new products or not. An environment that doesn’t encourage its developers to read, study and learn new things seems to me to be the best recipe for turning its projects into boiling frogs by bad habbits and inefficient procedures. Worse yet, if you don’t get continuous input on how the rest of the world is tackling their problems you will probably never realize it either. Not even when the frogs are dead and buried ages ago.

Self-awareness and the need for innovation

I must admit I haven’t found any substantial evidence that one month of continuous thinking really is more productive in terms of new ideas compared to the same time chopped into afternoons and distributed over the year. I do however feel there’s definitely more to explore with this approach, and I have realized one thing: It’s hard to think outside the box when your spend your days chained into one. I can’t claim that a sabbatical is the magic formula, but I am very confident in the idea that you need to back off a bit if you are to conceive any original ideas, and doing that is a lot easier if you are on a continuous leave.

So, to the big questions: Is it really worth it? Do we really need to spend this time goofing off on side-projects, sabbaticals and conferences? Are we really in such a need of innovation when it comes to software development? Can’t we just stay in the office and write code as we always have done, without succumbing to these hippie methods? Maybe, maybe not. Truth is, your organization will probably not completely stop being creative just because you don’t let your developers loose. You will most likely continue to earn some money even if you don’t throw your employees at conferences. Your competition will probably not kill you in an instant just because you didn’t give your team Friday afternoons off for informal discussions.

In the long run however, it is my personal conviction that a bright future of our industry is completely dependent on people taking charge of creativity and innovation as serious concepts, thus taking actual steps towards it without leaning back on the cushions of empty words. I am also convinced it is extremely important to be self-aware of the current situation, and to cherish the ability to evaluate and acknowledge problems even if you don’t have any immediate visions of how it would work otherwise. If you live in Antarctica, you shouldn’t need a postcard from Saint-Tropez before you realize wow, this place sucks. Given that, you should also consider that there is one thing to acknowledge you’re in an undesirable situation and a different one completely to do something about it. You might down-prioritize the wider problems because you have others more present issues, but do not accept mediocrity in your development environment for the sake of comfort and simplicity.

If you’re hauling rocks to the pyramids, you might look at the river and think hmm, it should be a lot easier to transport these rocks if we moved them on the river on top of some kind of flotation device. Your slave driver might yell that’s preposterous, we don’t know anything about boats. Now carry that rock and taste my whip *slash*slash*. It is certainly true, you might not know anything about building ships, but that doesn’t change the fact that those rocks should be carried on water instead of people’s backs. Newton basically invented calculus on a whim because he needed some framework to describe the planet’s elliptic orbits. What’s your excuse? If you don’t know how to do it, then learn. Go figure it out.

To sum it up; Why are you still here? Go innovate! Go! Now!

Tuesday, 14 August 2012 - 23:43