Raimund Steger’s Professional Homepage

I am a software engineer in network and system programming, distributed applications, and databases. I also have several years of experience as network administrator for Linux, BSD, and MS-Windows environments. I currently work for Sopra Steria SE, a French consulting and software development company.

My goals:

• F/OSS first
• KISS/YAGNI
• zero fanboyism
• use industry standards

I have regarded myself an agile engineer throughout my career and mostly have been able to work in environments where people were trying to be that as well, which sounds like I've been lucky, even if what came out in the end was always quite different.

So what I have been observing is not that agile software development is everywhere. What I am observing is that all the businesses I come to seem to be in the process of embracing it. That is kind of weird, given I am talking about a span of twenty years. It's fine too. Agile is not for settling. It's for never leaving any stone unturned.

But agile development does not mean that:

• unit tests and coverage reports are all there is needed to control code quality (people are sometimes barking up the wrong tree here);
• every API can be regarded as self-documenting.

Writing meaningful tests (be they automated or not) and documentation is the challenge it ever was.

In Extreme Programming Explained, if I remember correctly, there is a statement that is both wise as well as dangerous. It says that documentation should be treated as a user story, just like any other.

It is wise because the effort should be visible and incentivized. It is dangerous because it means you are asking for budget. It is an approach that makes sense when documenting to external consumers because that's lean – do what matters in the end result. Try to provide code for the rest, including infrastructure … well, if you're not just doing one-shot stuff.

In the unlikely event that there are dollars to spend, keep the following documented (which sometimes means deleting old material):

• onboarding/howtos
• design rationale

There is the sort of documentation that is needed to meet quality gates when hiding an agile project behind a waterfall facade. What this usually means is copying to MS-Word what ought better be in JavaDoc. There is rarely any useful bit of information in such documents, even when they were written by actual waterfall people. If there is any chance, leave it out. Don't program in Word. Program in code.