Bruce F. Webster

The very first class I took when starting my computer science degree from Brigham Young University was CS 131. I forget the course title, but the teacher was Dr. Alan Ashton, a quiet, self-effacing but brilliant professor who would later become very, very rich by developing — along with Bruce Bastian (with whom I shared a TA office for an entire school year) — the WordPerfect word processing program.

Dr. Ashton was an outstanding instructor. I took this class in 1974, and all our programming was done on an IBM 360/65 mainframe in 360/Assembly, on punched cards no less. Yet Dr. Ashton thoroughly inculcated in us the concepts of structured programming, having us (for example) come up with half a dozen different ways of implementing a WHILE loop in assembler.

At the same time, he did his best to teach us the realities of software development and engineering. One of his comments in class seemed so axiomatic that I immediately thought of it as “Ashton’s Law” and have quoted it as such ever since:

Ashton’s Law: Whenever someone tries to do something for you, they usually end up doing it to you.  — Dr. Alan Ashton, 1974

I have long lost track of how many times over the past 34 years I’ve thought of Ashton’s Law or have spoken it out loud to others. Dr. Ashton made the comment in the context of operating systems, software tools, and applications; all we have to do is look at something like the User Account Protection in MS Vista to see that Ashton’s Law is all too much alive and well.

But there is a deeper issue here in software design and implementation, which I’m also sure Dr. Ashton had in mind. When two software components have to interact, there is usually an explicit and documented (by the source code itself, if by no other means) interface for one component (the ‘called’ component, for lack of a better term) that the other (the ‘calling’ component) makes use of.

In designing functions or services of the called component, we often end up as perpetrators of Ashton’s Law. That is, in our desire to do something for those who will invoke these functions or services, we end up doing something to them.  We make decisions about preconditions, calculations, and results that may seem quite reasonable to us, and that we may have the best intentions for; still, our decisions may lead to others cursing our names (or at least our functions).

There are always tradeoffs in software development among such desirable features as reliability, performance, memory footprint, calling/service standards, security, simplicity, and so on. Our priorities — even our requirements — may differ from those who will use our component’s functions and services, and so a certain amount of friction is perhaps unavoidable. What we can do is spell out all our assumptions and restrictions, and the reasons behind them, so that those using our functions and services know what they’re getting (or not getting).

However, there may exist also what is variously termed a deep, hidden or undocumented interface for the called component. This deep interface deals with invisible and often unknown requirements, side effects, and consequences of a given function or service provided by the called component. For example, the function or service may leave some aspect of the software system or the host computer system in a different state (e.g., changes to internal data structures, changes to files or databases, launching or killing of processes, and so on) without making that fact explicitly clear in any documentation or the API itself. You may feel there is a good reason for this, but it may also interfere with the calling component’s on-going functions.

As with much of what I post here, this may seem quite obvious to you, but trust me — obvious or not, it’s incredibly common and quite frustrating for those having to use the offending software. As software engineers creating software components, systems, and applications to be used by others, we need to constantly keep Ashton’s Law in mind and ensure that we are truly developing useful functionality for others instead simply making their lives more difficult.  ..bruce..

Sorry I haven’t posted much lately; I actually have a few posts in draft status, but I’m currently in Dallas, pouring over hundreds of pages of source code listings (Z8 assembler, anyone?) and haven’t had a chance to finish up any of them. In the meantime, here’s my latest Baseline column on the challenges of a (geographically) distributed software development project. Part II will be on techniques to help make such an effort successful; feedback is always welcome.

[Response to comments -- WordPress for some reason won't recognize that I'm signed in and let me post directly in comments myself]

Yurri writes:

It’s true that managing a distributed team is much more challenge than having all your crew at the one office. It’s definitely true but obvious also.

To you and me, perhaps, but not to to many organizations, large and small. Such organizations still operate — consciously or not — on the assumption that IT engineers are interchangable components, which includes a naive belief that it really doesn’t matter where all the IT engineers are located as long as you have enough of them. If you don’t believe me, consider how many organizations still consider it perfectly feasible to have a joint offshore/domestic software project.

The only thing that i can’t agree in this article is that oil prices play main role in distributed software development expansion. Tickets cost still remain minor part of relocation expenses as I can expect.

I must not have been clear enough. The sharp rise in gas prices encourages telecommuting — have IT engineers work from home, rather than driving into work each day. The rise in airline ticket prices also discourages having distant engineers fly for meetings as often as they should. I actually fully agree that the rise in airline ticket prices is relatively minor compared to (a) hotel and meals costs, and (b) the benefits of having all the engineers getting together — but I also know that many corporations often use minor expenses as a reason to deny something. Think about it: how many organizations refuse to buy their IT engineers up-to-date development systems and tools, despite the fact that the costs of such computers and tools is a tiny fraction of the engineers’ salaries and the lost-opportunity cost of having IT projects delayed?

John writes:

[key factors include team size, talent of the engineers, team cohesion -- go read his comment below]

I agree with all your observations. I’ve had distributed development work, and I’ve also had it cause real problems — and those factors pretty much were the difference. And, yes, I’ll be writing about that in the next column. ..bruce..

I previously discussed the up-and-down cycle of college enrollment in computer science and related fields. More accurately put, there have been two large peaks in computer science enrollment: one in the mid- to late 1980s (which happens to be when I was teaching CS at Brigham Young University) and another right around the turn of the 21st century.  Here’s the CRA chart I included in that previous post (click on the chart to see a larger version):

Back in 1985-87, while I was teaching at BYU, I mentioned to my friend Wayne Holder — one the finest software engineers I’ve ever known — that students at BYU could no longer simply declare their major to be Computer Science; instead, they had to take certain prerequisites, apply to the CS department, and be accepted. Wayne thought that was too complicated. He suggested that the prospective candidate be put into a room with (a) a bowlful of money and (b) some really nifty hardware and software. The candidate could then choose either to grab a handful of money and leave or to hang out and play with the computer gear; those who chose the latter would be admitted to the program.

I think Wayne was dead on, and this article in Computerworld (hat tip to Slashdot) tends to support that, though the survey quoted in from the United Kingdom rather than the United States:

Responses from nearly 2,000 undergraduates across the UK showed that most students think the IT sector has a bright future with good prospects for highly paid jobs.

But over 60% of non-computing students do not wish to enter the sector because they think it will be boring.

I’ve written before that talent is a key factor in IT personnel issues, and only a small portion of the general population appears to be talented in IT. People who have little or no aptitude for IT are likely to find it boring at best and confusing at worst.

However, that natural aversion to IT has been overcome at least twice in the last 30 years. The first time was in the mid-1980s and was largely a response to the explosive growth of the personal computer industry, led by Apple, IBM and Microsoft, but including many, many firms making both hardware and software. I wrote for BYTE Magazine back then, and individual issues of BYTE ran anywhere from 300 to nearly 600 pages, due to the sheer volume of ads. My observation as a CS instructor at BYU was that many of our students had come into the program thinking they were going become rich and/or famous, like Steve Jobs or Bill Gates.  They viewed computer science the same way my fellow undergrads a decade earlier had looked at law or med school. Hence the tremendous run-up in CS enrollment, not just at BYU but all across the United States.

Then came the First Tech Crash, which hit around 1988 — helped along, if not outright triggered by the stock market crash in October 1987 — and lasted into 1991 or so. Large numbers of hardware and software companies went out of business, and the personal computer market pretty much narrowed down to IBM and a small number of IBM PC clone manufacturers, with Apple treading water (at best). The chart above shows how CS enrollment mirrored that crash. By the early 1990s, the joke in the IT industry was: “Do you know what the status symbol of the 90s is? A job.”

CS enrollment nationwide was pretty flat from 1991 to 1997, and down at a level that you’d have to go back to 1981 to match. Most likely, people going into computer science at that time were — like me, all the way back in 1974 — going into it because we liked the field, not because we thought we’d be rich.

By 1998, however, the “dot-com boom” had become visible enough to start driving CS enrollment up again. There was an enormous demand for software engineers, with a lot of venture capital to back it up — news articles reported programmers being recruited out of high school, and CS graduates were getting large salaries and signing bonuses. Beyond that was the vision of the “nerd lottery” (to use Bruce Henderson’s phrase): dot-com startups would go public, and many of the startup’s employees (right down to receptionists) would walk away multi-millionaires. Mainstream corporations tried to get in on the dot com boom as well, starting various e-commerce and internet intiatives.

In just about this same time period, the Year 2000 (Y2K) problem got everyone’s attention, and even those organizations, both commercial and governmental, that kept the dot-com craziness at arm’s length found themselves having to do exhaustive testing and remediation of their IT systems from top to bottom. Business and government in the United States would end up spending $110 billion on Y2K remediation, all in just a few years.

As the chart shows, CS enrollement skyrocketed again, nearly tripling from 1997 to 2003, largely due to the combination of these two factors.  Unfortunately for those students, Y2K remediation largely finished up almost at the same time the Second Tech Crash (or “Dot Com Crash”) started, namely March 2000. The NASDAQ stock index peaked at its all-time high value of 5048.62 on March 10, 2000, a 100% increase over what it had been just a year earlier. (Stop and think about that: what if the Dow Jones Industrial Average were to hit 24,000 a year from now?) It was a classic bubble, and now it was popping, or at least deflating; the NASDAQ index currently trades at less than half that value. (Note that the DJIA is up roughly 20% — and was up over 30% earlier this year — from its value on that same date eight years ago.)

This tech crash was far more brutal than the first one. The IT employment marketplace was flooded with massive numbers of IT engineers who were no longer needed, one way or the other, and even talented IT engineers had a hard time getting visibility over the sheer number of warm bodies out there.  But it took a while for that feedback to get back into the colleges and universities; enrollment continued to climb until about 2003 but appears to have been slumping since then (see the chart above) and could actually drop back nearly to where it was when I graduated with my own CS degree some 30 years ago.

In other words, the real issue isn’t why CS enrollment is declining; the question is why did it ever climb so high in the first place? And it’s pretty clear that it tracks the two major bubbles of the past 30 years: the personal computer boom in the mid-1980s and the dot-com/Y2K boom of the late 1990s. After each bubble deflates, CS enrollment sinks back to its “natural” level, based on the distribution of IT-related talent and inclination in the general population.

The problem, however — as I first noted over 12 years ago — is that this “natural” level isn’t enough to supply sufficient IT talent for successful IT develompment and deployment in all the businesses, vendors, government agencies and other organizations that need it.

In my opinion, there is no shortage of IT engineers — particularly not after the vast numbers drawn into the industry due to Y2K and the dot-com boom — there’s just a shortage of talented ones. This is why you get conflicting claims and statistics about “personnel shortages” in the IT industry (cf. here vs. here, as well as the battle over raising the limit on H-1B visas and the offshoring debate).

The various attempts to “boost” CS enrollment at colleges and universities will have only a small effect on that talent shortage; for the most part, it will likely bring additional people into the IT industry who lack the talent or inclination to do well there.  In other words, it won’t solve our IT problems at all.  ..bruce..

In response to my Baseline columns on metrics (Part 1, Part 2, and Part 3), I received the following e-mail:

I read your column with great interest as I’m involved on an IT project to measure productivity. May I ask you a quick question? Are there any mature metrics that can measure tester productivity improvement month by month and accurate to 1%?

Here’s the response I sent back:

Well, for starters you have to define what you mean by “tester productivity.” Number of test scripts run? Number of defects found?  Number of defects closed? Number of defects reopened? (And do you weight the “defects found/closed/re-opened” by criticality and/or severity?) Number of reported defects replicated? Number of hard-to-replicate, yet critical/severe defects that can now be replicated (and thus fixed)? Some combination (possibly a weighted function) of all of the above?

In other words, what is it exactly that you’re trying to accomplish? To make your testing team more effective? More efficient? To shorten the test cycle? To spend less on testing? To close more defects (and defer fewer open ones) for each system release? To have fewer defects discovered after a system release? Jerry Weinberg says that “quality is value to some person.” Who are the people you’re worrying about, what qualities — functionality, performance, reliability, etc. — do they value, and to what extent?

Once you’ve defined all that, there still remains the question as to whether you can measure that to a 1% accuracy (or even a 10% accuracy) month over month, and still preserve any meaning in that measurement. It’s possible (and common) in metrics to have “false accuracy”  — you believe you’re actually measuring something to a certain precision, but you’re mostly just reading random or insignificant noise at that level.

Finally, we come back (as always) to Weinberg’s law of metrics: that which can be measured can be fudged (or exploited). For example, read this story over at the Daily WTF:  The Defect Black Market.

Hope this is of some help, though I tend to doubt it.

Thoughts from the rest of you?  ..bruce..

My newest Baseline column is up: “Lies, Damned Lies, and Project Metrics (part 3)“. In it, I wrap up my discussion on IT project metrics, outlining a possible approach using instrumentation and heuristics.  Go check it out.  ..bruce..