Agile has swept over the development world. It has become so popular because it works. One of the principles behind the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” You get your user story, quickly get working software and iterate based on feedback.

How can we use this principle to improve the productivity of individual developers?

Let me share a valuable lesson I learnt a while back. I had a friend who was very productive when writing. He published articles and stories at an astonishing rate. All this on top of his full-time day job. When I dropped in one day, I noticed his typing style was very different from mine. He kept typing without coming back to make changes and corrections. He ignored spelling mistakes, bad grammar, left sentences incomplete and just kept typing. Only after he had typed around a page or two would he come back and make corrections. My own style of writing was very different. I used to write a couple of lines and stop to think about what I had just written. I used a lot of backspaces to make corrections and lots of mouse clicks to correct the horrid red spelling errors. Much of the time I would stop and stare at the screen wondering what to write.

My friend, on the other hand, was doing what I call “Agile Text Writing”. He shot off two pages of text very quickly, maybe in five minutes. He then made plenty of iterations on this draft. Asked people for their opinion and rewrote the draft based on the feedback. After watching him, I started writing articles in an agile manner and I found I was also very much more productive. One way to get into this way of writing is to stop using the backspace and delete keys. When writing your first draft use your editor like an old fashioned typewriter. Come back later and do all the editing. This is a terrific way to get those long complicated mails out as well.

How can we apply this to coding?¬†Coding seems to have no similarities to writing articles and stories but there are principles we can carry over. As we write code we need to think of good variable names, decide the variant of the function that we would like to use, think about the right control flow, think through all the use cases and error flows. We have to make a lot of micro decisions. Most programmers, when writing code, stop frequently and stare at the screen, maybe refer to documentation – like I used to do when writing articles. This “Stop and Go” style of coding is the result of all those micro decisions.

Can the principles of Agile Software Development and Agile Text Writing be used to create an Agile Coding Style?

My friend Charles and I kept experimenting with this and after many iterations ūüôā came up with a style of coding that we call¬†“Mark and Move“.

Type code without worrying about the micro-decisions.¬† Choose the first variable name that comes to your head. Choose the first variant of the function that comes to mind. Don’t worry about the exact control flow.

Does this sound like the dark and dangerous road to spaghetti code? Hold on, there is more to Mark and Move

Mark all variable name by ending it with zzx. Sprinkle your code with //to-dos. Get a working skeleton of the function within five minutes. Then come back and revise. If you find the variable name that you used was nice remove the zzx, but if you are able to refactor, then do it cleanly. If you can’t come up with a good name leave the zzx (it means you haven’t got sufficient clarity yet), you can change it in the next iteration. Address the to-do items. Take a few iterations if you have to.

When we taught this style to a few people they found that it made them far more productive when coding. They just blazed through writing the code, using Mark and Move. Then they would come back and with a few iterations create the final code that they would check-in. This way of coding actually reduces the time it takes to write good code by 40% to 50%.

Mark and Move is one of the techniques we teach in the PowerBoost workshop that make developers more productive. I will discuss more techniques that we teach in future posts on this blog.

I wrote this blog post using Mark and Move and it needed 7 iterations before I could publish it. When writing the first draft of the article I just put down that “it needed xxx iterations”. I replaced the xxx with 7 when I actually published it. I had an idea for this blog post in the morning, the first draft was ready in fifteen minutes. And the full article was ready to publish with a couple of hours of effort. When I don’t use this method,¬† I have a partial article that hangs around for a few days in the draft folder and bits and pieces get added and finally gets published after a week or so.

A Caveat:

This post is emphasizing a specific point. You are more productive when you separate thinking / design, execution and quality at a micro level. When writing code and articles you switch between these haphazardly, making you far less productive. It does not mean that initial thinking / design is not necessary.

If you use this technique to write articles you must first write down 5 points that you wish to highlight in the article. Similarly when using the PowerBoost process, one of the other techniques will give you a design against which you are writing code.

Techniques like these are part of the PowerBoost Framework.