When the office clock chimes 5 p.m., Joe Programmer promptly leaves the “if” statement he was wrestling with to hang in cyberspace. He shuts down his computer, locks the cabinet and heads out the door. Next morning, at 9 a.m. sharp, he is back in front of the computer to hammer down the “endif”, and the prescribed number of lines of code, until the big clock once again chimes 5 p.m.
But this Joe does not exist. He never did. Why, then, did his working style figure so prominently in the minds of those who designed the most beloved programs of all — the time reporting applications?
While the software development profession still tries to sort out its identity as either a science or an art, many practitioners know that when it comes to time reporting, it is more like an assembly line job. A fixed number of hours a day (same number every day), must be fed into the timesheet. Try to enter four hours for Monday (because, in all honesty, that’s what you were able to spend in a productive way), and enter 10 hours for Wednesday, when enlightenment finally hit you. Not all timesheets are that smart and some will test one’s work ethic.
When it comes to time reporting, computer work is often saddled with the inheritance of practices from the bygone industrial era. Productive work — not to mention inspiration — does not necessarily happen between 9 a.m. and 5 p.m. The flexible work schedule in IT is now a reality; modern technology lets us work anytime, from almost anywhere. But the time sheet application and the whole project management machine it feeds still operates on the eight hours a day assumption. Many programmers spend considerably more hours on the job without counting, because they have to or they want to.
We still need the eight-hours-a-day convention, for project management, and for life management. However, time reporting utilities and methodologies do not always keep pace with the reality and the specifics of work in IT. With teams working on multiple projects in the same timeframe, it is indeed a challenge to keep track of who worked on what project and when.
While professionals in specialties such as technical and call centre support still have to be on a strict schedule, those in research, analysis and programming benefit less from that kind of model. Trying to impose a rigid schedule on someone who is more productive after 12 p.m. is ultimately counterproductive. Measuring and controlling the work by deliverables and deadlines is a more realistic approach, one that the Agile paradigm seems to have figured out.
Should time worked also include breaks? Studies and anecdotes alike have shown that when people talk around the water-cooler and exchange ideas in an informal way, there are more chances for creativity and better relationships within the team, compared to when everyone just sits in the cubicle or attends the scheduled meetings.
In the industrial world, unless a worker is in front of the assembly line, he is not producing. But with software, it is not that easy to tell. A programmer might be circling the building and come back half an hour later with the solution for his problem. Was that walking or working? Someone else might have had a breakthrough while (or after) taking a “mental break” by surfing the Internet or playing Solitaire on the computer. Was that work? Yet another person is just surfing the Net or playing games on company time. Hard to say who is working and who isn’t, and even harder to measure or enforce the daily eight hours of (productive) work.
While a lot of sophistication goes into tools and processes for estimating the amount of effort to complete an IT project, when it comes to keeping track of the effort actually spent, things are many times relegated to subjective estimates or perceptions. One project manager confessed that tracking work is a daunting task, so “when it comes down to the point that I don’t feel good about the contractor overtime, I cut the contract short.”
Clocks not withstanding, it is time that the true nature of the profession got more recognition built in those inescapable daily management practices and tools.
QuickLink 056127
— Andronache is a Toronto-based application developer who works for a large IT firm. She can be reached at [email protected].
Related links:
Overcoming work and information overload – two experts show how
