CSC 640

Midterm Paper
Phil Ulrich

Analysis of Glass's Fact 7 - "Software developers talk a lot about tools. They evaluate quite
a few, buy a fair number, and use practically none."

Glass's fact #7 is, in short, about "shelfware" - software that is evaluated, purchased, and
then simply sits on the shelf. Glass purports that the main reason for this is the constant overhead
of schedules; in other words, developers have an uncompromising schedule that they must meet
at most times, one that cannot be set aside or pushed back to allow for the time to get a handle on
the benefits of a new tool of piece of software.
To be sure, there are other forces at work besides simply not having the time to learn how
a new tool will benefit the developer. Jarzabek and Huang discuss, using CASE tools as their
example, how sometimes tools simply don't fit well into a developer's workflow, and would be
less likely to end up as shelfware if they simply improved their productivity in a natural way,
rather than requiring the developer the substantially alter how they do work[1]. Yet even this is
just another way of looking at the primary cause that Glass has already presented - that
developers are under tight schedules, and cannot stop to work a new tool into their workflow, no
matter how modern it is.
Glass actually proposes in a much earlier paper the idea of a minimum standard software
development toolkit[2]. This may not address the problem at all, however. A minimum standard
software toolkit would only provide a baseline for software development, which actually seems
to have more to do with Glass's fact #6 (about how learning new tools decreases productivity
initially). Fact #7 has more to do with estimation than with the tools themselves - developers do
not yet know if the tool they evaluated and/or bought will fit into their workflow yet because
they are most often under a deadline to complete a project. Once it is proven that it would be an
appropriate product, then one can worry about decreased productivity due to a new tool, but until
that time, one can assume that estimation is the primary cause of shelving a tool.
Another cause for the persistently high amount of shelfware might be less of an
organizational barrier and more of a personal barrier - resistance to change. Riemenschneider et
al correctly identify willingness to change as a factor for adoption of a software methodology[3];
it could be said that adopting a new tool is simply a change in methodology. This is supported by
Brykczynski and Small, who in speaking of adoption of new software (specifically ISMS) in an
organization say, "if the... implementation does not change people's behaviors within the
organization, it becomes shelfware."[4] Brykczysnki and Small were not speaking specifically of
development tools, but the evidence is there - people within IT fields are resistant to changes in
the way they work, and this change can lead to already-evaluated software being placed back on
the shelf, never to be used.
Jeff Atwood brings up what might be another reason - the difference between 'alpha geek'
programmers and everybody else. Atwood estimates that programmers are divided into 20%
'alpha geek' programmers - that is, "the first ones to install Linux at home in the 90's; the people
who write lisp compilers and learn Haskell on weekends "just for fun"; they actively participate
in open source projects; they're always aware of the latest, coolest new trends in programming
and tools." Alpha geeks, as Atwood describes them, would be the ones doing the evaluating of
software tools, deciding which new trend might best benefit their workplace. The other half of
developers, the 80%, are, "the bulk of the software development industry. They're not stupid;
they're merely vocational. They went to school, learned just enough Java/C#/C++, then got a job
writing internal apps for banks, governments, travel firms, law firms, etc. The world usually
never sees their software. They use whatever tools Microsoft hands down to them -- usally
VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java
development. They've never used Linux, and aren't very interested in it anyway. Many have
never even used version control. If they have, it’s only whatever tool shipped in the Microsoft
box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough
to get their job done, then go home on the weekend and forget about computers." Atwood then
goes on to describe the fundamental divide between these two camps, and how the 20% are often
stymied by the 80% when it comes to introducing new changes and tools in the workplace.
Given that the bulk of software developers, assuming Atwood's estimates are true, do not
care about improvements and innovation and only care about getting their job done, it is easy to
see that a perceived lack of innovation might be yet another reason that Glass's fact #7 rings true.
"Sure, this could help me save five minutes," says the non-alpha programmer, "but what's the
point? I'd have to relearn everything I know, and that's time spent not doing my job." The alpha
programmer finds him or herself frustrated, but the non-alpha is ultimately following the
company line, shoving innovation to the side in favor of just getting the job done.
So while Glass's fact 7 certainly rings true most times, especially when you consider his
reasoning of tough schedules caused by (as he later asserts) almost assuredly poor estimation,
there are definitely other possible causes. Anyone seeking to introduce an innovative tool into
their workplace must take into account not only scheduling, but also vocation versus innovation
among developers and resistance to change as possibilities.
[1] S. Jarzabek, R. Huang. Case for user-centered CASE tools. Communications of the ACM,
vol. 41 no. 8, p. 93-99, August 1998.
[2] R. Glass. Recommended: a minimum standard software toolkit. ACM SIGSOFT Software
Engineering Notes, vol. 7 no. 4, p. 3-13, October 1982.
[3] C. Riemenschneider, B. Hardgrave, F. David. Explaining software developer acceptance of
methodologies: a comparison of five theoretical models. IEEE Transactions on Software
Engineering, vol. 28 no. 12, p. 1135-1145, December 2002.
[4] B. Brykczynski, B. Small. "Securing your organization's information assets." Software
Productivity Consortium.
[5] J. Atwood. "The Two Types of Programmers." Coding Horror.
<http://www.codinghorror.com/blog/archives/001002.html>