On Anzeneering, Pride and the Definition of Done (DoD)


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”.


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.”

About Hayim Makabee

Veteran software developer, enthusiastic programmer, author of a book on Object-Oriented Programming, co-founder and CEO at KashKlik, an innovative Influencer Marketing platform.
This entry was posted in Agile, Efficacy, Psychology of Programming and tagged , , . Bookmark the permalink.

2 Responses to On Anzeneering, Pride and the Definition of Done (DoD)

  1. Gil Broza says:


    I fully agree that the DoD should say something about the quality of construction, something like Mike’s “well written”. Should we go further than that and expect the developers to be proud of their work? I’d like that, and I’d ask teams to consider that option, but I would also expect many teams to push back. If you consider the pace of business and the constant pressure to do more, I would expect some to scale back to “code is clean”, “no serious code smell”, or even “we’re not embarrassed to ship it”. And perhaps that would be an appropriate response. What do you think?


    • Hi Gil, thanks for your comment. I think that we are not looking for developers who are “idealistic” or “perfectionists” about their code, we want them to be aware of the business constraints. This would be the difference between being an “artist” and being a “craftsman”.

      For example, I think developers should understand that sometimes it is acceptable to incur some Technical Debt to increase the Velocity of a Sprint. In this case we give to the developer the autonomy to make a decision based on a trade-off between the quality of the code and a business goal (Velocity).

      So I think the important point here is that the developer is not being forced to produce bad code. He can still be proud of his work even if there is place for improvements.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s