Agile: Starting a new project

This one is intentionally going to be somewhat vague. I’m starting a new team this week (we’re using Scrum, and I’m going to be the scrum-master), and I was talking about this with various project-manager/scrummies on the multi-team project that I’m presently on. We were discussing lessons learnt, ideas, tips/suggestions etc. about sprint zero.

I’ve been on Agile projects for several years, Scrum for a couple of years now – both as a developer and as a project manager. I’ve been playing a scrum-master role for the last year – on a large team that I picked up six months after it had been started. Now, it’s time for a new team.

Sprint zero would include setting up the backlog, getting product owners aligned, getting developers who’ve not necessarily used a lot of real Agile practices before educated about things, figuring things out around the architecture, deciding what to track and how, deciding on length of iterations, and so on and so forth. Basically everything that might come to mind when starting a new project.

I’ve got several ideas put together for what might be a good way to go about this – but what are the top few things that come to your mind when you start a team?

Turing complete languages and productivity

I was having a conversation with a colleague about varying levels of programmer productivity – specifically around language choice. As usual, one of the things that came up was the idea of Turing completeness. The important point to note is that the idea of Turing equivalence is completely separate from expressibility, efficiency, convenience, or well – productivity.

My take on it is this – for simple systems and programs – this idea of languages being equivalent approaches triviality. For non-trivial systems, however, the story changes quite a bit. If the system is sufficiently complex (and needs to be indistinguishable from magic), the best way to do it in a lower-level but “equivalent” language like C or Java is to build abstractions like crazy. Including building an interpreter for a higher level language.

I think that is the only way one can truly claim that languages are equal. Java is “equal” to Ruby because you can use JRuby to write all the code of consequence. C is infinitely superior to C++ when you embed Lua in it. Or Blub is better than Smalltalk because you implemented a Lisp in the former.

After all, what does it mean to write a system in a particular language when you can throw in a completely different layer of abstraction through a library like this? When these lines are blurring so much, and programming models and paradigms are becoming incestuous, is it not time to stop having silly debates about languages and start building systems with what works best?

P.S. – Of course, to be able to do the right thing, you need to have a toolbox with the right tools. Start collecting them, now!