Write code faster with Agile Writing


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.

If you liked this article why don't you subscribe to the blog. And if you have questions or opinions please do share it in the comments.

Athletes Vs Developers

Coaches train athletes/sportspersons to improve their performance.

Companies train developers to improve their perfomance.

Are we missing out something when we train developers?

How do coaches improve the performance of athletes and sportspersons?

  • Coaches train them on skills specific to their sport / events.
    • Footballers get trained on dribbling and shooting, batsmen on their stance and bowlers their grip. Sprinters get trained on starting from the blocks.
  • Training on playing well as a team.
    • Footballers get trained on passing the ball, cricketers throwing to the wicketkeeper, sprinters passing the baton.
  • Practice exercise to improve strength, stamina and agility.
    • These attributes are essential irrespective of the specific game. They also "carryover". If you have good strength and stamina and change your sport, it will be useful in the new sports
Pie Charts_sports.png

How do companies train developers?

  • Training on specific skills and technology.
    • C++, JAVA, AWS, node.js
  • Training on working well as team.
    • Scrum, Agile and other processes
  • The missing piece ???
    • What training will help developers regardless of the language and technology?   

The missing piece is training on certain fundamentals that allow the developers to deliver well engineered and well-designed code at speed.

These are picked up "on the job" if the programmers are lucky to get a good team lead or mentor.

A few examples

  1. How to read code.
  2. How to make code modular and less interdependent.
  3. Writing Readable code
  4. Systematic Design
  5. Debugging
  6. .....

Do you agree? What else would you add to the list?

Can Asterix help you recruit developers


At one point in my career I used to do all final interviews for developers in an organization (Tally Solutions Private Limited if you are curious). Everybody was astonished by the dramatic improvement in the quality of programmers joining. I will let you in on the secret.

When I was a kid I used to love Asterix. I enjoyed those comics, so much, I read and re-read them often enough to have memorized them. (Of course this was before the days of TV, computers and Internet so entertainment was fairly limited :-) )

Goscinny the Author and Uderzo the Illustrator; I loved them. It was a while before I realized that the original was in French and it was translated by Anthea Bell and Dereck Hockridge. I think Anthea Bell deserves a lot of credit for the world-wide success of the Asterix. Her translation is brilliant.  They say a good translation is an art. Let us look at some things necessary for a good translation.

  1. You should understand the source language very well. Well enough to understand subtle nuances like puns, meaning based on the cultural context and so on.
  2. You should write fluently in the destination language. Well enough to make puns, jokes which make sense in the different cultural context and so on.

  3. The art of understanding the source text and choosing the appropriate words to make an attractive, readable text which conveys the same “mood” as the original text. You can’t translate relying on a dictionary

What does this have to do with recruiting developers? Developers translate “requirements” to “code”.

  1. They should understand requirements easily.
  2. They should code fluently and have a good understanding of the impact of the decisions they take about data structures and algorithms on the code they write. 
  3. Write “good” code which gets the “mood” of the requirements.

In my final interview I used to ask an open-ended question, maybe “Let’s design a word processor or a hospital administration system” I didn’t put the whole question in the beginning, I would frequently in the middle of their answer, say “Oh I forgot something, you also need to take care of xyz”. I would notice how well and easily they understood the requirements. If they asked questions which I would probably have told them a little later in the interview they got extra points.   

When they had a working answer, I would make comments about the code which would only make sense if they had understood what they done and more importantly why they had done it?

To get selected they should have understood the requirements well and the nuances of the choices they had made.

Will this insight help you get “good” programmers into your team?