The concept of Anzeneering was created by Joshua Kerievsky, CEO of Industrial Logic and author of the book “Refactoring to Patterns“. It is derived from the Japanese word “anzen” which means “safety”. According to Joshua:

“Anzeneers protect people by establishing anzen in everything from relationships to workspaces, codebases to processes, products to services.”

“Anzeneers protect: Software makers from poor working conditions, including hostile relationships, death marches, burnout, hazardous software (poorly designed, highly complex, deeply defective code, lacking even basic safety nets like automated builds or automated tests), insufficient testing infrastructure, poor lighting, uncomfortable seating, excessive work hours and insufficient exercise.”

I think one important aspect of Anzeneering is the protection of software developers against the production of low-quality code. Note that the emphasis here is not on the negative business consequences of having poor software systems. Anzeneering focuses on the negative impact on the developers themselves. When programmers are forced to produce bad code, they cannot be proud of their work, and will suffer because of that.

Frank Sonnenberg, award-winning author of the book “Managing With a Conscience“, addresses similar issues in his article “If You’re Not Proud, You’re Not Done“. According to Frank:

“If you don’t put your heart into your activities, if you hand in incomplete work as finished, if you don’t do your best every time you start something, then you’re doing yourself a tremendous disservice. The truth is, if you’re not proud of what you do, you’re not done.”

“If you don’t do your best, you’re only developing bad habits, damaging your reputation, and letting your team down.”

And this brings us to the concept of Definition of Done (DoD) in Agile software development.

Definition of Done (DoD)

In Agile software development, the Definition of Done (DoD) are the acceptance criteria that must be met for a new feature (user story) to be released. Here is the DoD definiton by the Agile Alliance:

“The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment ‘often a user story’ is considered ‘done’. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.”

A concrete example is provided by Mike Cohn, Agile consultant and author of the book “Succeeding with Agile: Software Development Using Scrum“, in his article “Multiple Levels of Done“:

“A typical DoD would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems.”

In Mike’s example above it is not sufficient for the feature to be implemented, what is normally called “fully-functional”. The code may be complete, correct and still have lots of Technical Debt. Thus Mike says “the code is well written”.

Conclusion

Following the Anzeneerign approach, I would add to the DoD that the developer must be proud of his work. If a programmer is not proud of the code he wrote, he is not done, even if his code satisfies all the other requirements.

I want to end with a quote by Ed Yourdon, a pioneer in the field of Software Development who unfortunately left us last month at age 71. In his book “The Rise and Resurrection of the American Programmer“, Yourdon writes:

“If you think your management doesn’t know what it’s doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.”