Getting It Done Quick and Cheap

What do you do when your boss says, “That is just too long!” or “We can’t afford that!”?

There are things that can be done to improve your lot in life.   Barry Boehm (Boehm, 1981) devotes a chapter to the key approaches.

One very valuable approach is “Plagiarize!”.  Well, no, not in the sense we crack down on at the University .  A company owns the documents and software it has produced previously.  Software reuse is the art of finding code, ideas, designs, etc. that you already have somewhere that can be put to new use in the current project.  This takes planning and management on the part of the organization as a whole to be really effective, but even within your own group you can get big payoffs by looking for them.

I once was tasked with designing a report generator that sorted data, extracted information from a wide variety of existing flat file structure, joined the data together, produced formatted output that could mix tables with automatically laid out paragraphs, set margins, calculate sub-totals, produce cross-tabulated reports, etc., etc.  The only problem was, the development group could only afford one programmer for a month for the first release, and a few more staff months for the remainder of the project.  What could I do?

My resulting design called several Unix utilities “under the cover” to do much of the work: sort, join, awk, nroff, etc.  These were already available with the operating system itself.  The total effort was about what was allowed for, and the report generator actually exceeded expectations dramatically.  The approach had some performance penalties, but not enough to prevent later users from building it into real-time applications.  The total time required to write the initial draft of the requirements and design?  Eight hours (in the middle of the night).

According to Yourdon (Yourdon, 1993, p. 35), the best organizations have 60-70% of their software coming from reuse, while the average is 20-30%.  That can make a dramatic difference in productivity.

Another key approach is the Principle of Top Talent

“Use better and fewer people.” (Boehm, 1981, p. 668)

Many human resources people hate this principle.  They will fight to place upper limits on the amount you can pay anyone to do a job, whether for salary or on contract.  That is “cost control” by their way of thinking.  The unfortunate side effect is to prevent you from hiring the best people, who are often the most expensive.

This happens because it is easier to measure the cost of the people than their quality, and HR people have to deal with people manufacturing reasons to pay their staff better.

Studies show that the difference in productivity of the best people far outweighs the extra cost per person.

I worked for one organization long ago that had just given up on its old way of doing things, which were based on what I call the Principle of Bottom Talent.

“Use the cheapest programmers you can find.”

The director of programming in one office had been an ambulance driver in his previous job.  Six months of college was considered a lot of education.  People programmed in Pascal on the companies products by being given a Pascal book the day the decision was made to change over from Basic.

The results were awful.  Code was buggy and undocumented.  Each of the 40 customers had their own version of the software.  When a bug was fixed in one version, no one knew if it even existed in the others, so the company waited to see if the other customers would report it.  Thus, a bug that existed in the common parts of the code would be fixed 40 times.  Did they save money doing it this way?  No.  An outstanding programmer would have only had to fix it once, and would not have demanded 40 times the pay.

One co-worker used to “brag” that the company’s software had gotten more vice-presidents of customers fired for buying it than any other product on the market.

Using cheap people is good if they are great.  Using expensive people is bad if they are bad anyway.  Good people who are expensive are usually worth the money.  Bad people who are cheap aren’t.

References

Boehm, B. (1981). Software Engineering Economics, Englewood Cliffs, NJ: Prentice-Hall.

Yourdon, E. (1993). Decline & Fall of the American Programmer, Englewood Cliffs, NJ: Yourdon Press.