An interesting take on the Hawthorne Effect

While I was taking my undergraduate courses at Michigan State for my Bachelor’s of Computer Science, I took a Human-Computer Interaction course taught by Dr. Eileen Kraemer, a visiting scholar from the University of Georgia. In the course, we talked about the Hawthorne Effect and how it can create unintended results during usability studies.

The Hawthorne Effect is based upon research findings that have shown that participants in a study behave differently than normal when they know that their progress is being monitored. Often this comes up in usability studies, as some of the participants results can be questioned to the fact that the user may not have done what they just did had a researcher not been standing next to them. This is one of the major flaws with formal usability research.

To solve this problem, some software will track data anonymously and report it back to the software company. This data can be referenced and presumed to be absent of the Hawthorne Effect since users can be assumed to using the software in their normal ways without feeling like they should perform actions in a different way than normal. Often this is found in prerelease alpha/beta software, but it is becoming more of the norm with final releases where the market of testers expands exponentially.

In the usability realm, the Hawthorne Effect is something that researchers would like to limit. Yet in the project management realm, the Hawthorne Effect is actually something that is strived for.

In Peopleware: Productive Projects and Teams, the authors make a compelling point to try for the Hawthorne Effect on their employees. They claim that changing environment variables in the workplace to provide a better working environment will indeed obtain more work performed by the employees. This change in workplace environment is due to the Hawthorne Effect, since employees will be generally open to the idea (as long as it is not drastic), and will increase their output. Yet this Hawthorne Effect will wear out with time, and so they propose changing up the environment often, and that with this chaos will bring a better return on investment.

I found this approach to the Hawthorne Effect very interesting, since it is a complete reversal of the approach that usability researchers have on the Hawthorne Effect. Instead of trying to minimize the Hawthorne Effect, these project managers are trying to harness it. The Hawthorne Effect was actually coined from some research at Hawthorne Works, a large factory complex outside of Chicago, which was based on changing lighting levels in the workplace and noticing differing levels of increased output.

I wonder why I had never looked at the Hawthorne Effect from this angle before?

Finished reading Peopleware

Today I finished reading Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister. The book is about project management and working with teams to get the most out of the knowledge holders and deliver a great product.

I’m not a project manager and I don’t have plans to be one. I very much like developing software and getting my hands dirty in algorithms, interfaces, unit tests, and more. But reading this book gave me a perspective that being a software developer doesn’t.

There are so many aspects to supporting a software development team through a product lifecycle. I learned great examples of what not to do. Some of these are: paging employees over a loud speaker system when phone calls or visitors come in; requiring developers to answer their phone so it doesn’t get rerouted to administrative assistants; and a whole slew of others.

I even learned that in Australia, a common form of subordination from employees is not to strike when they are upset with working conditions, but to follow all practices “by the book”. Code submissions that once took a day now take a week as the developer tests the software on twelve different platforms, goes through many code reviews, and profiles the slightest of change. Doctors use this same “by the book” practice to force a regular appendectomy to take a whole week.

The whole “by the book” was really interesting, since it called attention to two problems that workers were facing. First, they were unhappy with a specific work condition, and they were also making noise about unrealistic practices that were meant to be followed yet would never make sense in reality.

Peopleware is a little old now and as such doesn’t cover new agile software development techniques. The ideas in the book are still worth a look in to, and it’s short reading at only around 230 pages. I recommend it to you if you’re ever curious how to be a better project manager or simply what goes through the head of your project manager at times.

Proper Units for Task Estimation

Yesterday during a planning meeting, some fellow developers provided rough time estimates for some features that have been requested by the business team. The estimates looked like the following:

• Create awesome feature X – 2 weeks
• Resize GUI component Y – 3 days
• Capture more meta information – 26 days
• Support better use of internet tubes – 4 weeks

Much planning and thought goes in to numbers like these. There are often many smaller tasks that comprise one of the estimates given. But out of any of those estimates, did any strike you as out of the ordinary?

It turns out that while those estimates might be spot on, they either don’t leave much or create far too much room for error. According to the Pragmatic Programmer, there is a lot of weighting determined by these numbers. Estimates given in weeks are often budgeted to be off plus or minus a week or two. Estimates given in days are often budgeted to be off plus or minus a couple days.

Therefore, the two week estimate is a shorter time span than the 26 day estimate, yet is given much more cushion room. Estimating a large task can be very hard, as a task that may take 26 days or 4 weeks almost screams that there are plenty of unknowns.

Here is what the Pragmatic Programmer recommends:

Duration	Quote estimate in
1—15 days	days
3—8 weeks	weeks
8—30 weeks	months
30+ weeks	think hard before giving an estimate

So what should have those estimates looked like?

• Create awesome feature X – 14 days
• Resize GUI component Y – 3 days
• Capture more meta information – 4 weeks
• Support better use of internet tubes – 4 weeks

Moral of the story: be wise when using units of time for estimation because product schedules depend on them.