Product and Productivity

A recurring advice for job seekers is to show how they helped in improve a company’s profitability. That may work in sales, but is a bit more difficult in IT. IT – like construction – usually works against moving targets. Specs change. The effect of spec changes is sometime indirectly proportional to what project manager’s estimate is. The ‘little’ change that requires a re-design. On the other hand, I have often encountered changes that were rather trivial, would have improved a system, but were not implemented, since they were outside the original scope of a project.

So how does a programmer contribute to the bottom line, and how do you measure his productivity? Number of lines of code went out with the dodo bird. Bug free coding has issues too, since it takes take time to create bug free code. Very important for some applications like when coding for a nuclear power plant. Mostly speed of development is more important. I have a brother who has 2 engineering degrees, who I used to think of as a ‘Cray super computer running on a 5 megahertz chip’. Slow is his middle name, but he has 0 deficiencies (or close to it). A common job requirement is ‘attention to detail’. Attention to detail takes time.

Since metrics for assessing productivity in code development are problematic, many companies decide that face time must be it. In order to be more productive we need longer face time which translates into 12 hour days at the office. One of the problem with long hours is that it encourages workarounds rather than finding a better solution. Pile on the code. Like old high school essay habits. Brain dump and hope something useful comes out. Taking a break or sleeping on a problem results in better solutions than brute force problem solving.

Then there are design flaws. Not that a design is inherently bad, but it may not help workers do their jobs. The question is: do you design a system that helps people do their current job or do you design it to the jobs they are supposed to do in the future. Change management through software implementation. Sometimes a system is designed by analysts and managers who do not understand the work the users do:

‘System is riddled with “design flaws” that see workers jumping through hoops just to do basic tasks — such as adding a new child to a welfare case, a move which now takes over 100 steps” from six” ‘.(Carrie Poole-Cotnam with the Canadian Union of Public Employees, criticizing a new $240-million Social Assistance Management System).

The programmers may have been incredibly productive project management always ‘on-the-ball’, so the end users get a not-so-useful system faster.

The real difference is not so much the speed of development (unless the timing of a new product release is critical for market share), but the value of a product. As a junior programmer I spent 3 months adjusting the screen interface to fit a specific type of monitor. Every user interface program had to be modified. When I was done, it was discovered that an alternative to code changes was available, and I did a delete *.* on my directory. So much for productivity and helping the bottom line. There are more of those projects around than one would guess, especially in larger companies or the government. The ‘Build and Discard’ model. It can be a change in technology or change in management and direction. New managers often like to change things. Sometimes that is the reason why they were hired in the first place, to change things. Other times they will do it because they can and to create an environment where they feel more comfortable and competent. So at the end of the day it is not how many lines of beautiful or not so beautiful code you write, but if the project/product is useful. The end-users decide.