Work Units and Discrete Measurements
Over the years, several bosses have impressed me with the need to measure work in a non-subjective manner.
Hours spent is a poor measure of progress; on the other hand, contractors attempt to protect themselves from absurd situations by charging for hours worked. When an employee works at a steady pace, measuring by the hour seems reasonable. The problem with computer programming is that progress is not usually uniform across time. Some large shops have tried to set dollar rates per hour for certain kinds of programmers; rarely have I seen the practice personalized to the specific worker, though some large shops move employees from from one category to another.
As a supervisor of co-workers, I have expected my co-workers to spend observable hours and also to make reasonable progress. The question becomes "What is reasonable progress?" My friend Errol was fighting cancer; his skills had declined and his focus had narrowed. Nevertheless, we agreed to work on short term tasks of a few hours each. He did well and I was satisfied; my boss was satisfied.
Demoted from Salary to Hourly
The current trend to categorize computer programmers as hourly workers greatly aggravates me. Two large, local businesses had IT shops with primarily salaried employees and the management took the duties of typical programmer-analysts and split the jobs into analysts who rarely program and programmers who rarely analyze; then the managers claimed that neither role was creative or independent enough to be on salary. The same employees were reduced to hourly workers.
Work Units need some granularity. The following have worked well enough: xxx5
Hours spent is a poor measure of progress; on the other hand, contractors attempt to protect themselves from absurd situations by charging for hours worked. When an employee works at a steady pace, measuring by the hour seems reasonable. The problem with computer programming is that progress is not usually uniform across time. Some large shops have tried to set dollar rates per hour for certain kinds of programmers; rarely have I seen the practice personalized to the specific worker, though some large shops move employees from from one category to another.
As a supervisor of co-workers, I have expected my co-workers to spend observable hours and also to make reasonable progress. The question becomes "What is reasonable progress?" My friend Errol was fighting cancer; his skills had declined and his focus had narrowed. Nevertheless, we agreed to work on short term tasks of a few hours each. He did well and I was satisfied; my boss was satisfied.
Demoted from Salary to Hourly
The current trend to categorize computer programmers as hourly workers greatly aggravates me. Two large, local businesses had IT shops with primarily salaried employees and the management took the duties of typical programmer-analysts and split the jobs into analysts who rarely program and programmers who rarely analyze; then the managers claimed that neither role was creative or independent enough to be on salary. The same employees were reduced to hourly workers.
Work Units need some granularity. The following have worked well enough: xxx5
With contractors, the work units tends to be the entire project. While a down payment is common, the contract is finished when the project is finished; then payment is made.
CPM and Work Units Each box represents a task. A project has a certain number of boxes. Using the number of boxes completed gives a method of calculating a percentage done. Verifying correctness at each task is a typical short-coming of this method. As all the boxes become done, the project seemingly approaches 100 percent done; if the tests reveal errors, then what percent is done. On the other hand, if major failures are rare, the method can provide a measurement of completion. |
Why is Percentage Complete important ?
Maybe percentage complete is not important. If the number of days estimated for a collection of boxes matches the number of days spent on the project, then the progress appears as expected. When a project might take many days, having some measure of progress is important. The manager needs to prepare for the next project; the manager might need to meet with the customer when the progress is slower than expected. The manager might need to remove some impediment from the project that seems behind.
It is not done until it is done.
Jerry Nakano ran several large projects on which I worked. He could be very demanding and rude. He quickly lost humor when projects did not go as expected. Even when the project was going well, he could become agitated by small deviations, even positive ones. Jerry did pay well. On Fridays at noon, he would have a meeting at a restaurant. He would ask how many hours we would spend by Saturday late; then he would write a check to each of us for the number of hours that week,
Jerry's work unit was pretty much one program. When a program had been written, tested, and installed, that work unit was counted as complete. Our project at Richey Electronics had more than forty programs and some function libraries and some utilities. Jerry divided 100 by the number of programs; each program thus had a value of about two percent. Even still, he expected about five complete programs per week. After we incorporated some semi-interpretive techniques after finishing about ten programs, we stayed well ahead of expectations. The project finished more than a week early.
Each Project helps to Perfect the Estimates
As much as managers like when programmers meet schedules, programmers like when managers estimate well. Managers need practice and experience. Thus, managers should prefer projects that finish several times per year. Managers also should prefer similar or repetitive projects. Under the Diagonal Method, the manager strives to projects whose tasks follow well-chosen paradigms. The purpose is to make the manufacturing of software more predictable. In a similar example, at Lakeside Bridge and Steel in Milwaukee, Wisconsin, workers built prefabricated bridges. The company manufactured an average of more than twenty bridges per week. Civil engineers across the Midwest bought the bridges mostly for county roads. After years of manufacturing bridges, the estimated times were within a few man-hours per model of bridge. My great grandfather and grandfather ran Lakeside.
Always something new; Paradigms still work
In the last forty years, data processing has changed every year. The term data processing has given way to variations of Information Services or Technologies. The result is that the paradigms change. Nevertheless, the typical shop can usually start with very similar paradigms: Even choosing a poor paradigm simply leads to more adaptations sooner.
Maybe percentage complete is not important. If the number of days estimated for a collection of boxes matches the number of days spent on the project, then the progress appears as expected. When a project might take many days, having some measure of progress is important. The manager needs to prepare for the next project; the manager might need to meet with the customer when the progress is slower than expected. The manager might need to remove some impediment from the project that seems behind.
It is not done until it is done.
Jerry Nakano ran several large projects on which I worked. He could be very demanding and rude. He quickly lost humor when projects did not go as expected. Even when the project was going well, he could become agitated by small deviations, even positive ones. Jerry did pay well. On Fridays at noon, he would have a meeting at a restaurant. He would ask how many hours we would spend by Saturday late; then he would write a check to each of us for the number of hours that week,
Jerry's work unit was pretty much one program. When a program had been written, tested, and installed, that work unit was counted as complete. Our project at Richey Electronics had more than forty programs and some function libraries and some utilities. Jerry divided 100 by the number of programs; each program thus had a value of about two percent. Even still, he expected about five complete programs per week. After we incorporated some semi-interpretive techniques after finishing about ten programs, we stayed well ahead of expectations. The project finished more than a week early.
Each Project helps to Perfect the Estimates
As much as managers like when programmers meet schedules, programmers like when managers estimate well. Managers need practice and experience. Thus, managers should prefer projects that finish several times per year. Managers also should prefer similar or repetitive projects. Under the Diagonal Method, the manager strives to projects whose tasks follow well-chosen paradigms. The purpose is to make the manufacturing of software more predictable. In a similar example, at Lakeside Bridge and Steel in Milwaukee, Wisconsin, workers built prefabricated bridges. The company manufactured an average of more than twenty bridges per week. Civil engineers across the Midwest bought the bridges mostly for county roads. After years of manufacturing bridges, the estimated times were within a few man-hours per model of bridge. My great grandfather and grandfather ran Lakeside.
Always something new; Paradigms still work
In the last forty years, data processing has changed every year. The term data processing has given way to variations of Information Services or Technologies. The result is that the paradigms change. Nevertheless, the typical shop can usually start with very similar paradigms: Even choosing a poor paradigm simply leads to more adaptations sooner.
- A simple data entry screen for one data table
- A simple data entry screen for two parent tables and one child
- A complex data entry screen for some major functionality, like purchase orders
- A simple inquiry screen
- An inquiry screen that covers at least one major business function, like purchasing or payroll.
- A data import program
- A data export program
- A simple listing
- A multiple level report with four control breaks like customer, inventory category, part number, and month
- A good report program based on the cascade algorithm or similar
- A complex report like accounts receivable statements and summary
- A standard screen to launch batch jobs
- A standard batch job
- A web page for display of information
- A web page for collection or input of information
- A library of shared functions