(author: Roland Rashleigh-Berry
date: 28 March 2004)
From Large to Small
Seeing this sub-title, you may have thought that "large to small" was referring
to downgrading a mainframe computer to a smaller Unix server. But that
is not what this section is about. Instead, it describes a way of thinking
that is (or has become) Unix. An alternative approach to "thinking large"
which is to "think small". As a Clinical SAS programmer, I am used to seeing
programs being copied from one study to another, constantly being "enhanced"
to satisfy presentation needs for reports. What starts off as a small simple
elegent program slowly evolves into a very large program that many would
call a "monstrosity". But all this springs from the idea of "thinking
large". If you write and maintain large programs then it is quite natural
that they become ever more large and complex. They eventually reach the
state that they are large and cumbersome, and yet essential to the reporting
needs, so that work on them is slow and you need substantial manpower to
keep the status quo. Ever increasing manpower and growing inefficiency.
Higher costs that tempt the management of companies to attempt to cut the
cost, often by farming out the work to other countries where the labour
is less costly. But if everyone involved, "thinks large", then there is
no escape from this situation. To escape the situation, we have to reverse
our thinking and "think small" instead. Thinking small does not
mean that we should shy away from producing the reports that people require.
These will still be required. Thinking small refers to thinking in small
units. Large applications can be built using small, simple, semi-independent
units. Units that are simple to write and maintain. If you have a good
set of these units and understand them well then you have the potential
of using them as building blocks to create large applications. In this
way it can be done quicker and more reliably and greater efficiency can
be made.