Productivity is a very satisfying feeling. Achievement, in the simplest sense: being able to look back and say, “I have done this”.

I like to have clear markers of progress even in small things. It makes the achievement more concrete and solid. My “to do” lists are tangible, on pieces of paper, because I like the feeling of crossing off tasks one by one and seeing the list shrink. Especially at times when I feel that I am not getting much done – because of tiredness, or because I spend more time learning than producing, or just because I am new to things and not able to move as fast as I want to – the act of crossing off a to do item reminds me that I am actually moving forward.

Not that producing is more important than learning. (If I thought that, I’d still be churning out Excel models with great efficiency, and getting paid very well for it!) But learning is such a never-ending process that it is easy to become oblivious of the speed at which it is happening. There’s an excellent Swedish word, fartblind, that means “speed blind”. In the concrete sense, when you’ve been driving on a motorway and come to an exit, it’s easy to underestimate your speed – and likewise when you’re driving on a very smooth road in a very quiet car. In the figurative sense, it’s only when I do something with what I’ve learned, that I can see, yes, I have actually learned this, I know this now. I need landmarks, lamp posts to help me judge the speed.

From a ticking-off-tasks point of view, this week ended on a very pleasant note. Yesterday and today I submitted my first two formal Change Requests. Once the developer, that is myself, has finished making whatever change I’m making, I need to submit a request for the change to be incorporated into the system (which really deserves to be called The System) – all changes go through a formal process before they’re approved and rolled out. The Change Request explains the reason for the change, summarises the changes made, and links to each of the files that have changed. Submitting a Change Request doesn’t mean that everything is done, but it is a landmark.

These two change requests were not just good because they were the first.
#1 was exciting because each of the steps leading to the Change Request was done on my initiative. The project was given to me, and it was up to me to get it done. Getting it done had me asking a lot of very basic questions and getting a lot of help, but the process was all mine.

#2 was interesting in a completely different, educational way. Out of the ca 15 files involved in the change, there were 2 java source files, 5 configuration files for The System, 4 input files for another proprietary application, 1 Excel template and 3 config files for a job scheduling application. That’s a lot of configuring and very little code. In fact, if we find ourselves making more changes of this sort, the code will be rewritten so that subsequent changes wouldn’t require any code changes at all.

All of which made me realise much more clearly how little of software development is really about code, and how much is about the systems and processes around it. Both in terms of importance, and in terms of how much time they take. It’s something I knew in my head but not in my bones, because I hadn’t been involved in anything like it before.

It would seem that the less code-focused the development process is, the better – because that probably means it is more robust. Processes add overhead, but they also add stability and scaleability. Like a skeleton, really. The formal change management system that we have, for example, may take time, but having an established process means that I do not need to worry about it – I can be sure that a suitable someone will review my changes, and that the changes will be rolled out. And it provides both traceability and transparency: both myself and anybody else can see all the details and the status of the change request at any time.

Perhaps it’s just a personal preference, of course. I like transparency, explicitness and clarity. It seems to echo the GTD approach that I use for keeping my own life in order. I don’t like vague manual processes where you’re sort of supposed to get various people’s approvals, but you need to hunt them down one by one, and then you need to keep chasing them to get their replies, and they will all want to know what the others have said, and it’s never quite clear whether you’re done or not.

Phew… this came out quite a bit longer than I had planned. I have had a week of activity and no blogging, so I guess there was a fair amount that needed to be flushed out of the head. And the two posts I had planned on productivity and on processes appear to have become one.