Sunday, April 21, 2013

The
primary usage of software is collecting data. As it is collected, it
gets used to automate activities directly for the users. A secondary
effect from this collection is the ability to monitor how these
activities are progressing. That is, if you've build a central system
for document creation and dissemination, you also get the ability to
find out who's creating these documents and more importantly how much
time they are spending on this effort.

Monitoring
the effectiveness of some ongoing work allows for it to be analyzed and
improved, but it is a nasty double-edged sword. The same information
can be used incorrectly to pressure the users into performing artificial
speedups, forcing them to do unpaid work or to degenerate their quality
of effort. In this modern age it isn't unusual for some overly
ambitious upper-management to demand outrageous numbers like 150% effort
from their staff. In the hands of someone dangerous, monitoring
information is a strong tool for abuse.They do this to get significant
short-term gains but these come at the expense of inflicting long-term
damage. They don’t care, they're usually savvy enough to move on to
their next gig long before that debt actually becomes a crisis.

Because
of its dual nature, monitoring the flow of work through a big system is
both useful but also difficult. It is done well when it gets collected,
but is limited in its availability. Software that rats out its users is
not appreciated, but feedback to help improve the working effectiveness
is. One way of achieving this latter goal is to collect fine-grained
information about all of the activities, but only make it available as
generalized anonymous statistics. That is, you might know the minimum
and maximum times people spend on particular activities, but all
management can see is the average and perhaps the standard deviations.
No interface exists for them to pull up the info on a specific user, so
they can’t pressure or punish them.

Interestly
enough, when collecting requirements for systems, fine-grained
monitoring often shows up. Not only that, but there is usually some
'nice sounding' justification for having it. Most of software
development these days is oriented to giving the ‘stakeholders’ exactly
what they want, or even what they ask for, but this is one of those
areas where professional software developers shouldn't bow directly to
the pressure. It takes some contemplation, but a good developer should
always empathize with their users -- all of them -- and not build
anything that they wouldn't like applied to themselves. After all, would
you really be happy at work if you had to do something demeaning like
punch a timecard in and out? If you don't like it why would anyone else?