Evaluation based on results is not the answer to long working hours

Shinzo Abe, Japan’s Prime Minister, has announced that Japan needs a more flexible working style without the ridiculously long hours that prevent many women from working. This is a very laudable goal and something that Japan will need in the face of a shrinking population and many in the younger generation that seem reluctant to devote their lives to the company. (Typically, the photo accompanying the article about improving working conditions for women shows a committee that consists almost entirely of old men.) In fact, changes are already happening, albeit very slowly. When I started working in Japan 14 years ago many colleagues came into work on Saturdays and nearly all stayed very late. Many still stay fairly late but the company has prohibited Saturday working and is putting limits on overtime.

What really worried me in the Yomiuri article though was the quote:

“I would like you to investigate a framework for a new working-hours system that befits work styles evaluated based on results, not time,” Abe said at the meeting.

This sounds like Abe wants to replace one dysfunctional system with a different but equally dysfunctional one. A shift from the bureaucratic nightmare described by Northcote C. Parkinson to one based on industrial age thinking.

The Yomiuri article hints at the problem by describing the “entrenched system of long working hours suppressing productivity” and suggests limiting working hours as the solution. However, the problem is in the working culture that equates dedication to hours worked and working harder as the means to achieve more. Changing this will be harder than just limiting overtime. Which is probably where the focus on results comes from, companies worried about their revenue probably want that to ensure nothing actually changes.

The suggestion in the article is that employees could work whatever hours they like so long as they achive the results. This sounds remarkably like management by objectives which is strange from a country that so admired W. Edwards Demming who had “Eliminate managemement by objective” as one of his 14 points for running a company. The problems with this approach are legion. It discourages teamwork and it puts the focus on the individual instead of the system as the source of productivity. It also assumes that it is actually meaningful to measure “results” or productivity at an individual level.

To improve productivity it is necessary focus on the system. Ironically it is Japanese companies such as Toyota that have shown the world what can be achieved by doing this. Yet Abe’s statement demonstrates that this is an exception, even in Japan rather than the norm. I see this problem daily at my own workplace. Long working hours are considered normal, this gives no incentive to actually improve the working practice since you are going to be in the office anyway. And even when there is a desire to improve the system everyone is so busy dealing with what John Seddon calls ‘failure demand’ that there is no time to introduce improvements.

From the perspective of software development this means that developers are so busy debugging the code that they have no time to consider how those bugs got there in the first place and what changes they could make to prevent them. “We don’t have time to do unit testing or code review”. It is very hard for them to change the system, so simultaneously making them responsible for their results while limiting the only thing that they control, their working hours, is both demotivating and unfair.

Update: A nice article from Vangard Consulting puts the case against "management by results" in the health care sector very clearly:

Wherever management by results exists so too does the failure to accurately understand and sustainably solve systemic problems. This is in the nature of management by results because:

1. It wrongly assumes that performance can be adequately described by a system of measurement; and
2. It holds people and organisations to account for the fictions that this creates.

Another book from Packt

Packt asked me to review another book for them; this time on Review Board.  "Getting Started With Review Board" by Sandeep Rawat. Maybe they didn't actually read my previous review of the QtCreator book. After I replied that I would be happy to write an actual review, that would probably be bad,  rather than just an endorsement I didn't hear back from them

Review Board is a great tool. I have been using at work now for several years. It is a free open source tool for code review. In the very early days the setup required installing several packages but for several versions now the setup/upgrade process has been made trivially easy. It uses the python easy_install tools so normally the install, including all the pre-requisites can be done with a single command. It also has great online help and installation instructions. It is also very easy to use. I find that new users in my team just need a 5 minute explanation of the main features and they are good to go.

Which brings me to the Pack book. It is described on their web page as

This book is a concise, to-the-point guide with a practical walkthrough of the code review workflow using the features present in Reviewboard. 

Based on the table of contents and the sample chapter what this means is that the book is simply a very short description of what reviewboard is. The sample chapter on "Reviewing Code Review Requests" was simply a description of the Review Board features that are not only easy to figure out for yourself they are also described fully in the free help with the program. The book will also be out of date very soon since Review Board 2.0 is about to be released.

So I don't really understand the point of this book. Why would anyone want to spend $12  for the eBook or $22 for a paper book for something that is not really needed and available for free online.

What would actually be useful is a book on how to do code reviews. Karl Wieigers "Peer Reviews in Software: A Practical Guide" is one of the best books on the subject that I have found. Smart Bear also have a free eBook on code review available (requires registration) which while obviously meant to advertise their code review tool does discuss code review in general. However, there are not so many books that cover code reviews.

The publisher of the book is often a good indicator of the quality of the book. Some publishers, like The Pragmatic Programmers are always reliable.  I think I will be avoiding Packt books in the future.