We're doing Agile, right?

Agile Software Development has taken off big time: it appears on every one's CV, you can do M.Sc's in it, all the cool guys are into Agile. And we're doing it too.

No.

Agile cover a multitude of methodologies but I'll stick to one of the first formalisations: Extreme Programming or XP. This made a number of trade offs: you don't have to do A because you're doing B which will cover the same ground. The obvious side effect is that if you're not doing B you're in trouble.

Let's look at some concrete examples. Programmers like to program so the release from large scale up front design is often welcomed. Up front design is used in waterfall development to ensure that the group know what they're all trying to build an that the final product has a suitable architecture for the task at hand. So how does XP (or any other Agile approach) handle this?

DRY

Don't Repeat Yourself. If you see a piece of duplicate functionality, factor it out. This provides a retrospective design to your software. But wait, changing software is dangerous so you'll need

Comprehensive Test Suite

With good test coverage there's little risk involved in modifying code and if you do something stupid there's always your buddy to fall back on.

Pair Programming

Let some one else look at the code you're writing. They'll pick up mistakes you've made, point you at other bits of the system that look similar and be some else to fix the bugs whilst you're on holiday.

The important thing to notice is that all the pieces are entwined. If you don't refactor the code you'll end up with spaghetti code because you didn't do big up front design. If you don't have comprehensive test suites your refactoring will break things. If you don't pair program or code review then, in the absence of design documentation how does the system architecture get communicated?

Agile development is a high discipline approach to software development. It forgoes some of the safety nets of traditional software development and instead utilises other practices in an attempt to improve development efficiency. If you ignore the replacement practices you've no longer got a safety net and you're just hacking at code till it sort of works.

Org-mode and Microsoft Word

One of my less enjoyable tasks is to produce a weekly status report following a particular look. This then gets emailed off and compiled with others. Unsurprisingly the format has to be Microsoft Word and no one ever gets the use of format styles correct.

Editing the pro-forma always has me cursing: delete one character too many and fonts change, bullets appear or disappear, all the usual joys of Word.

Emacs, and more specifically org-mode to the rescue. Org has had the ability to export in several formats (typically LaTeX and HTML) for quite some time but now boasts support for OpenDocument format too.

So my status reports are now written using Emacs with a line setting org-export-odt-styles-file to point at a hand handcrafted OpenDocument template file. That sorts out the presentation aspects of the final document. C-c C-e o exports my text to OpenDocument then open that in LibreOffice and save as Microsoft Word format. The conversion from ODT to docx format can be automated: soffice --headless --convert-to docx myfilename.

I wouldn't say that I actually enjoy writing my status reports now, but at least it's considerably less painful, I can just get on with writing information and not with fighting the tools.