On programming in the summer

In the summer my training and consulting business gets quiet. That allows me to take some holiday and to pursue some stuff I don’t get much time for otherwise. This summer I’ve picked up a programming idea I started last summer, worked on over Christmas and still haven’t finished. This means I’m programming!

It is getting close to 10 years since anyone paid me to programme but I dabble a bit, I keep my hand in (a little). Right now I’d like to share some observations I’ve made. Programmers out there – please agree or disagree, just leave comment below. And if you haven’t programmed for a while then think about these points.

A bit of background, I’m working in Python (2.7) for the Google App Engine. It is about 2,300 lines of HTML and 4,000 of code and unit tests. I’ve set myself a challenge of doing this without a debugger. Just unit tests and some debug logging/printf’s if needed. I won’t have an IDE either, I’m using TextMate. Giovanni Asproni persuaded me to try PyCharm but the thought of learning another IDE stopped me installing it.


  1. Its addictive – hard to stop, when you see your code working its hard to step back, not to play with the kids, not to eat and even not to go the toilet!
  2. Sometimes it feels like your brain will explode, you are just trying to keep so many things in mind at one time and make sense of something (or somethings) new, and understand how it all hangs together and…. you just feel full.
  3. It scares me – knowing that I will be so immersed scares me, I don’t pick it up and do little bits when I can be cause I know I’ll get sucked in.
  4. It requires large chunks of time – its not like answering e-mail, its not something you can do 5 minutes here, and 20 there, you need a few hours at a time, partly because of #1 and #2 above.
  5. Them tests – TDD development makes it so much more enjoyable, yes its hard to keep yourself honest but when you see a little bit more working it feeds the addiction; it also means you spend less time with those annoying little bugs and trivialities. Once or twice I’ve strayed from writing tests for too long and ended up in a mess.
  6. Trivial tests Yes! – when I evangelise TDD I often get asked by people “But surely you don’t need to write tests for all the small, obvious stuff, getters and setters say”. (Leaving aside the “you should’t have getters and setters” argument for a moment). Its hard to argue with them. But its perhaps with the trivial stuff that I find TDD makes the biggest difference, perhaps in part because I’m in Python and not a compiled language. Its those occasions when you think “this is trivial I’ll just do it” that often catch you out. I am not thinking, I am on auto pilot, or, heaven forbid, I’ve done a bit of cut and paste.
  7. No you can’t TDD everything (particularly in the UI or a third party system) but that means I go slower there, I’m taking more risk. I wish could test that stuff. Why should “not being able to test everything” be an objection to “testing everything you can?”
  8. Bigger problems, multiple things: some of the bigger problems you face are where several things come together, and sometimes it far from obvious that they have! (This is the same as my entry in 97 Things Every Programmer Should Know, Two Wrongs Can Make a Right.)
  9. Taking a break: sometimes when you are in the middle something, particularly if your brain is about to explode (#2), and/or you are convinced you are on the edge of completing something, or accomplishing a breakthrough (particularly if something is not working like you expect it to) then… you just can’t take a break. Not so much addition but the feeling that if you let go now you will never get it all back into your head again. But, big but, a break is just what you need. Only when you come back fresh can you actually make it work. Only a break will let you step back and think without the overload.
  10. Nothing else: When I’m programming, when I’m on a roll, I don’t want to write more Xanpan, or continue the User Stories series, or chase down some leads for work. Yes I should do all these things but… programming is good. There is only so much time in the day. Wouldn’t it be nice if I had someone else to take care of those things? If I was a team I could…. all those programmers who want to do away with managers should think about this. If you do away with managers much of that management work still needs doing and now the programmers are going to have to do it!

Its easy to see what attracted me to programming all those years ago. The deep immersion and challenge, man v. machine, it soaked up so many of my teenage days – particularly summer holidays. Its perhaps fitting that it is mainly during the quieter summer months – when my training and consulting work isn’t so busy – that I get time to do a bit of programming.

Something else thats funny, when I’m programming I really like listening to old 70s and 80s music, stuff I listened too when I was a teenager immersed in programming. Guess I’m just a middle-aged man seeking his youth!

#NoProjects pod cast c/o Tom Cagley

During August I’m in holiday mode, so by way of a change from blogging here is a podcast.

Tom Cagley has been doing podcasts for some years now under the title SpamCast – Software Process and Management Cast. A few weeks ago he interviewed me on the subject of #NoProjects and its now up on his website.

I’ve not had a chance to listen to it myself but I’m sure it was good.

Thanks Tom!

Xanpan now on Amazon

Regular readers will certainly know about my Xanpan method, a hybrid of Extreme Programming and Kanban. (The secret is: Xanpan contains XP).

Earlier this year I decided to make Xanpan into a more respectable book, that mean a new, professional cover:


Step two was proper ISBN numbers for the electronic versions. The print version has long had the number 978-1-291-85273-8, now the Mobi (Kindle) version has become 978-0-9933250-0-7, the PDF version 978-0-9933250-1-4 and the ePub (Apple Books) is 978-0-9933250-1-4.

And I’m please to announce step 3 is now complete: Xanpan is now on Amazon.

Unfortunately due to the way Amazon works it sees the physical and electric book versions as different books, and the different Amazon’s don’t show the same reviews. So, there are lots of views on Amazon just scattered around – there are also still reviews on Lulu.

Anyway, if you don’t have a copy of Xanpan yet you can now get it at:

I’d love to have more reviews, so please please please add them! I’m happy to give a (unfinished) copy of Xanpan 2 “The Means of Production” to anyone who writes a review.

And if you live in another Amazon country (.de, .ca, ….) then I’m sure your Amazon has the book, you just need to look at the UK or USA for reviews right now.

Team Start Dialogue Sheet

I’ve updated the Team Start Dialogue Sheet. Many thanks to Marta Kolenda who used the sheet with two of her new teams and sent me some feedback. Incorporating her feedback gave me a chance to make some more changes to the sheet too.

I’m always glad to have feedback from people and teams who try any of my Dialogue Sheets – getting feedback from Agile teams can be like getting blood out of a stone!

Plus I’m always keen to sit in and observe teams using the dialogue sheets – particularly the still new Customer Discussion sheet – so please invite me!

And while you are looking at the sheets… you might notice that Software Strategy – my company – has a shiny new website. Bblogs and books don’t pay mortgages so Software Strategy is my commercial side. If you know anyone who wants some advice or training on software development or Agile then point them here!