Daik.se

I changed jobs nearly two years ago. I moved from a really high velocity team at Frame to a Atlassian. At the time I thought that the velocity we had at Frame was the norm, and I was quite comfortable with it. It suited me to get lots of stuff done. I don't think we rushed ahead at the price of quality. Lets face it, software is always a 'banana product' in that it needs to ripen at the customer's house. We shipped bugs, for sure, but we were also very quick at fixing them. This blog post is about how I've come to deal with a significantly lower pace at Atlassian.

First things first, these are my own thoughts, and while it may sound like I am not all that happy, I am mostly happy. I would like to have a higher velocity but that is just about the only thing I would like to change. Throughout this blogpost I will refer to any humans as 'he'. This is pure laziness on my part. We all know that skill in a given subject has nothing to do with gender (if you don't, it is time to grow up). Therefore I am not going to do clumsy things like 'he or she' or 's/he'. I use the male version, but anything can just as well be said about a girl.

So compared to Frame what is my velocity now? It is hard to judge this actually, it is all about perception. My impression is that I have a velocity of about 1/5th of what I had at Frame. One fifth! Just ponder that for a few seconds, if I am right, I achieve in a week what I did in a day at Frame! Even if I am way off with the estimate and my velocity is just half, it is still significantly different. It frustrates me. Sure I have a much greater freedom now, I am allowed to create things that I would not be allowed to at Frame. 20% is great for creativity.

What slows you down though? Again this is very subjective but I'll try to think of things that make me produce less code.

Speed bumps

• The first thing I can think of is a massive but unreliable test suite. We have thousands of tests, yet it seems getting them to pass is next to impossible. I have during my two years never gotten the Selenium suite to pass. It is random test failures, more often than not, in things not related to my code. This is a huge productivity killer. If I get five failures, I have to investigate every single one, and determine that they failed for some other reason. I may loose half a day on such hunts.
  
  
• Second thing I can think of is an aging code-base. One of the problems with old code is that is becomes increasingly difficult to maintain. Of course that need not be, look at webkit (Safari and Chrome rendering engine), it started in 1998 and is written in C++. Yet they have an amazing velocity. What is different? The number of hacks, and bad code committed. The larger the number of hacks and "quick fixes" the harder it is to maintain. Writing maintainable code is hard, if you constantly look towards the horizon you will cause problems for yourself later on. I have a blog post in the making on this subject called 'Bad code is a social problem'.
  
  
• Code reviews. Code reviews are good, right? Yes they are, if they are used properly. As with all things, used right code reviews are brilliant, used wrong they will cause problems. I've gotten reviews that asks me to fix the indenting of the code. Now code style is important, but the time lost when it comes to opening the review, find what the reviewer talks about, fix it (usually just re-format the code). Commit it, observe if any test fails. If they are you have to check if the re-formatting actually broke something. It should not have, but it might and you still need to verify that it was not caused by your change. Another half day lost, just to re-format the file. Suddenly the format of the file seems to be not quite as important. Code reviews can also be very demoralising. You may have written something that reduces the time it takes to perform a task to 20% of the original time, but people get hung up on details in the review so you feel only criticised for the work, which brings us to the next point.
  
  
• Feeling demoralised. If you do not get proper recognition for the good work you do, you soon loose interest in your work. I am not saying that we should sing songs of praise for every commit, or that coders are babies. The thing to remember here is something Asimov touched on in profession. It comes down to creativity again. If the coder does not feel appreciated he will still create, but the creativity will be directed at things that are not work related. He will write code on the bus home, at home, on holidays and so on. This code will be written for personal benefit. I believe that any software company need to ensure that they capture the mind of their coders. If they do, all this thought and creativity goes towards the company and everybody profit. It is all in the rhetoric of the comments. What is said is important but of equal importance is how it is said.
  
  
• A myriad of other responsibilities. Constantly being stuck doing other things takes you 'out of the zone' Matt Welsh put it very appropriately, when he said "very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning.". You want to be in 'deep hack mode', or 'the zone' as much as possible, but being constantly distracted means you will never really get into deep hack mode. I remember last time I was in deep hack mode, it was before Sofia was born, in 2008. This is a hard problem to solve, because obviously sometimes the coder is the best person to do something. But reducing this, or setting aside specific time for it may work. I do not aim to provide solutions to all speed bumps, I just call them as I see them.
  
  
• Constant bug-fixing. Now this is closely related to the demoralised point above. Software has bugs, anything more than about 100 lines of code will have bugs, simple fact of life. However when you get lumped with doing nothing but fixing bugs you loose interest. What is worse is fixing someone else's bugs. I have not done much but bug-fixing since I started at Atlassian. I have done very little feature work. Some of the 'features' could be considered bug-fixing even. I have colleges who have not done anything but bug-fixing. This is a productivity killer. You need to be challenged, you need to do things that are interesting in order to achieve good things. I am not saying no to bug-fixing, there just has to be a balance.

Accelerators

That was my somewhat long list of things that slows me down. I think observers will note I did not list 'meetings'. Simply because I have very few meetings. I have the morning stand-up which takes about five minutes. Apart from that I have almost no meetings to deal with. Now what can improve velocity.

• Varying tasks. This pretty much goes without saying, you need to have a mixture of things to do. Some things need to be familiar and easy, other things should be new and unknown. Coding is a very interesting profession. It is often described as an art. And it is a creative endeavour, but it is also an engineering problem. Not too far from building bridges and houses. The concept of 'software engineering' may be contested but regardless of what we call it, it is not just creative, it is also required to be able to foresee things, and know what can be done with what tools are at hand.
  
  
• Good version control. No I really don't care if you use subversion, git, mercurial, or <fill in favourite vcs here>. Having one tool, with easy access and people knowing how to use it helps speed things up. It is just the age old 'each item has its place'. If you don't know where to find the source you are looking for, you will loose time tracking it down.
  
  
• Flexibility. Flexibility in both work times and work location is great and something Atlassian excels at. Most things can be done out of the office. Even the concept of 'office' is somewhat blurred with people working in Sydney, San Francisco, Europe, Kuala Lumpur.
  
  
• Tooling. We all have our idea of what the ultimate tool is, but not one tool can excel at everything. A typical example is development environments, or IDEs. Eclipse is a brilliant tool, but the UI does not click with me, so I prefer Netbeans which is equally brilliant. Making it easy to pick whatever tool you think is best for the task can greatly improve velocity. Atlassian fail here, while we do not have mandated IDE choice, everything is so geared around the IDE of choice it is very impractical to work in anything else.

So how have I dealt with the speed bumps I've run into? Most of them are things that are really out my hands. I've just come to deal with it the same way you deal with speed bumps on the road. You slow down, you drive over them and move on. There is just not a lot that can be done about it. I will try to fix things, but I've just come to accept that I will write far more code when I work on the six year old tool I am maintaining for Wexiödisk on the hour I have on the train home than I did during the day at the office. That is just life. I've shifted to a lower gear. Now I'll end this rant.