Tuesday, March 1, 2016

The rise of the second guesser

We seem to be in a world where the "second guessers" reign supreme. By second guessers I mean those people who don't do the work, don't necessarily have the expertise but do hold the power of the purse. Let's look at a few:

  • Health care audit companies. I go to the doctor. I get the treatment. A bunch of busybodies in a backroom then look to see if I should have gone, look to see whether the insurance should pay.
  • Education oversight. A bunch of busybodies telling teachers how to teach - often without ever having been on the front lines of a classroom
  • Consultants. A bunch of busybodies overseeing the work of IT development teams - without knowledge of the problem space. (And yes I am occasionally guilty here)
  • Travel administrators. A bunch of busybodies who administer travel programs without understanding how travel works.
  • Bureaucrats. A bunch of busybodies who impose policy without understanding how the activity being overseen should work - or works in practice.
  • ......
The list is endless. The thing they all have in common, however is that they don't bear any responsibility for the outcome, they exist to "manage costs" but actually add little or no direct value. They fall into the category called "waste" - something that ought to be eliminated in general. Of course, those being subjected to bureaucratic oversight do just enough to keep the bureaucrats off their backs and still, somehow, get the productive work done.

I wonder how much of our economy (and what proportion of employment) falls into this category. How much better off we might all be without such levels of waste.

Friday, January 29, 2016

Evolution of reuse/subroutines/functions/services Part 1

This post is a potted history of the ways we have seen reuse work in software over time. It is a somewhat personal history, starting with my first foray into software in 1967. I didn't invent any of this - but was a beneficiary.

The first exposure I had was when I did a summer internship at Gloucester Polytechnic in 1967. We were allowed to get our hands on a real live computer. Paper tape was the only mechanism for getting programs and data into the beast. The programming language was called City and Guilds Mnemonic code. It was an early teaching environment running on an ICT 1900 series computer. We were given the task of using Heron's formula for calculating the area of a triangle. This involves taking the square root of a number at the last step of the calculation.
The really important part of the exercise was writing the square root function in this very low level language. We were instructed to use a Newton-Raphson iteration method. This was quite tedious! After about 2 weeks I finally had this beast working. It was coded on paper tape using a machine like this.

The paper tape device had a useful feature - you could make an exact duplicate of an existing tape. That was how we corrected bugs in the program. Copy the working bit of the code. Stop the copy. Type in the new code. Advance the original to the point where you wanted to continue from and continue the copy. No wonder the square root took 2 weeks.
At which point, the instructor said, "You can't be the first people ever to create a square root function, so why do it again and again? Especially as there may be errors in your version."
He the pointed to a row of coat hooks. Above each coat hook was a DYMO embossed tape label naming a function. Hanging on each hook was a loop of laminated paper tape containing the code for the function.
The procedure was:

  1. Identify the function you need
  2. Locate the coat hook
  3. Take the tape loop
  4. Place the loop into the input side of the tape copy machine
  5. Position the tape on the output side where you need the function
  6. Copy the code from the input to the outside
  7. Remove the laminated tape from the input side
  8. Inspect for nicks/errors
  9. If the original is damaged or showing signs of wear, give it to the computer lab tech to have a new copy made
  10. Either the original or new copy of the function is replaced on the hook.
These physical images have stayed with me since then. And they help me as I think through the pros and cons of different coding approaches.
  1. First locate the subroutine or function (if one exists). The "FIND" step
  2. Make the subroutine/function available to the program. The "BIND" step
  3. Execute the program containing the function/subroutine. The "EXECUTE" step
Of course FIND/BIND/EXECUTE model doesn't tell you how to create good subroutines/functions. But it does provide a good thinking model for what has to happen when you want to use a previously developed routine.
  1. How do I know where to look? Where are the coat hooks?
  2. What searching ability do I have? Can I read the DYMO label?
  3. Do I inline the code (copy/paste in modern parlance)? or do I invoke it (lots of ways)? Inline was all I had
  4. Who has the ability to create new copies? Who are the lab technicians?
In other articles in this series I will look at mechanisms from link libraries, component libraries, shared functions, open source, services, micro-services and associated mechanisms for the FIND/BIND/EXECUTE model