Content hosted on-premises (and subject to occasional downtimes)
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.
- F/OSS first
- zero fanboyism
- use industry standards
I have regarded myself an agile engineer throughout my career and do not have any actual personal experience in heavyweight processes. Given that my first paid software development activity occurred in 1999, I suppose I can consider myself lucky.
What I am observing though 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. These processes are meant to be continuously thought about and be improved with the ongoing willingness to never settle, to never leave 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, 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. Still, it is an approach that makes sense when documenting to external consumers in a context where you try to provide code for everything else, including infrastructure.
In the unlikely event that there are dollars to spend, keep the following documented (which sometimes means deleting old material):
- 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.
••• Oracle Certified Professional: Java SE 11 Developer
••• EDB Certified Associate – PostgreSQL 9.6
••• Oracle PL/SQL Developer Certified Associate
••• Oracle Database SQL Certified Expert
New location starting 2017-01-01:
The old location (mail will no longer be redirected):