We will get to the Tindallgram I stumbled over shortly, but first, to understand these three perspectives, it might help to look at their opposites. What should you do to be a bad engineer?33 Or a bad manager.

1. Make your own judgments, even if they are significantly different from what the people doing the work think. The further removed you are from the actual work, the more important is confidence in your own judgment.
2. Learn about problems by reading reports from others. The briefer the report, the more problems you have time to learn about. When reality is different from what you would like, be assertive that reality should change, not your desires.
3. Focus on your own niche. After all, that’s what you were hired to do and you couldn’t possibly have anything intelligent to say about anything outside of it. Besides, it’s much easier to solve a problem when you can ignore everything around it, so why not just do that?

Most professionals I’ve worked with (including myself, to be clear!) do at least one of these opposites, sometimes all three.

Now, let’s look at how Tindall writes to avoid these mistakes.

When this Tindallgram was published on June 6th, 1966, nasa had received information from mit that the software that was going to space would be late. Tindall went to mit to see what could be done about the schedule. He met with, among other people, an Ed Copps. He writes that

I am very encouraged to see the enthusiasm and vigor with which Ed Copps is attacking the problem. […] Tom and I concluded that it would be better to accept this delay [which Ed Copps finds unavoidable] than for us to attempt to do the job ourselves, which is for all practical purposes the same thing he is trying to do.

Later in the memo we can read phrases like phrases like “A couple of items which Ed did tentatively identify”, “Ed asked us to re-examine the specification” and “Everyone at mit seems to feel that.” It is clear very quickly that Tindall trusts the workers.

Tindall uses “pacing items” and “pacing programs” to refer to the parts of the software that are especially late.44 Or, rather, that seem to exert most influence on the tardiness of the schedule. He continues,

Our main objective, of course, is to find out what the pacing items are so that maximum attention can be given to these items in an attempt to bring what is expected to be an unacceptable schedule more into line.

The mindset here is, I believe, absolutely critical for software development success: management is on the floor to figure out the facts, rather than trying to lecture workers on how to do their job. It’s also an admission of the continuity of the problem, in the sense that software can be late by varying degrees, and it’s not an all-or-nothing deal.

Further down in the memo, the trust-the-workers-but-find-the-facts stance is reiterated,

It is not our intention to dispute estimates of time required to carry out specific tasks, shortening the time to anticipate delivery, by telling them to do a job in two months which they feel requires three; although, of course, these estimates must be carefully examined to assure ourselves we are getting the correct picture.

Learning more about estimations is not a negotation tactic, it’s to more deeply understand the problems being faced by the workers.

Tindall gives some suggestions on how to handle the situation.

Possible lines of attack are as follows:

1. Review and, if possible, reduce or simplify our requirements involving the pacing programs.
2. Give top priority to programmers working on those routines for computer access.
3. Authorize somewhat inefficient use of computer storage by those programmers to speed up the coding process, even at the sacrifice of deletion of other routines.
4. Reassignment of personnel to the critical areas even though inefficient.
5. Reassignment of certain tasks from people working on the critical systems to other groups.

Clearly, Tindall knew a thing or two about product development. When facing a schedule slippage, the first instinct should indeed be to “reduce or simplify” requirements. A 2 % reduction in requirements can easily save 10 % of development time due to avoided innovation and fewer interaction effects.55 It’s effectively taking the saying that “The remaining 10 % of the code accounts for the other 90 % of the development time” and running it backwards.

I like that the personnel and task adjustments are listed last – they’re the least likely to be effective, and run risks of being rather disruptive, but they are still “possible lines of attack”. I should probably also make some sort of comment on how programmers needed to compete for computer access …

But, the thing I really want to draw attention to is how every point above, explicitly or implicitly, states a trade-off. Because everything in product development is a trade-off. Allow the programmers working on late software to write less efficient code to get done faster?66 This is a specific instance of Ward recommends, that every engineer working on a solution should know how to sacrifice quality characteristics to get done faster, if necessary. But note that this is still less efficient than simplifying requirements entirely. Sure, but that will mean their programs crowd out other programs that we wanted to run on the same computer – what do we do with those?

Tindall brings the problem into perspective by discussing the future nasa flight plans, and how they tie into the software schedule.

It is to be emphasized that we must look at the overall schedule situation and not just the program for a specific flight. There are obvious interactions and trade-offs that could be made between the programs for AS-207/208 and those for AS-503 and AS-504. If all efforts to remain within the flight schedule fail and the programs do become pacing for these flights – as they very well could be – we must be in a position to understand the trafe-off of flight schedule delays of one mission as compared to another.

This section is a bit specific to the schedule nasa was aiming for with their impending flights, but it shows that Tindall is not just looking at the software schedule in front of him; he is also considering the wider impact and changes that can be made to downstream processes to adapt to the schedule. He is suggesting making well-informed backup plans before they are needed.

Now think about the date of that memo: 1966! This was before the nato Software Engineering conferences in 1968 and 1969, which means the term software engineering was not yet invented. Yet this person seemingly knew more about software development in 1966 than most managers of software product development companies do today.

These are not new ideas, and sometimes it baffles me that they are not more widely known.