one chip as small as 32k in any laptop or desktop you would buy today.
There are libraries full of books on
languages, methodologies, and development lifecycle models. Modern systems development environments are
exactly that: environments. Integrated development environments (IDEs)
contain programming language syntax checkers and compilers, editors,
functional code and code snippet libraries, object browsers, code navigation and coverage aids, environment
support and virtual machine interfaces, authoring tools, configuration
management and build functions,
even embedded project management
capabilities. Critically, IDEs usually
contain interactive testing and debugging environments and this can
be where problems may arise.
These powerful tools allow us to
create something that “works” and
create it very quickly. From a standing
start, IDEs allow developers to build
and test complex systems in days if
not hours.
This is very seductive.
Low energy state
Humans, like most dynamic systems,
often attempt to operate at the lowest
energy state possible. When the perceived job of a software engineer is to
“build something,” and the environment provides a very quick way to build
something, it is difficult not to follow
that road to its end. Fast compilers and
interactive debug environments can
encourage shortcut approaches that
compromise the learning essential
to effective systems development. We
may build something when we really
need to build the thing.
There is instant gratification in coding and immediately seeing the code
run. It can encourage programmers
to throw something together and then
play with it to see how (or even if) it
works. At its best this can be considered learning by experimentation; at
its worst it can be mindless hacking.
thinking and experimenting
Don’t experiment when you should think;
don’t think when you should experiment.
—Jon Bentley, computer scientist
There are two ways to approach
understanding something. We can
think carefully about the required
logic to solve a problem before trying
to produce something that will show
how our understanding holds up. Or
we can experiment by running a pro-
gram in different states of develop-
ment against different inputs and see
what happens. Both are legitimate
approaches when used carefully and
thoughtfully. But we have entered
an era where computing power and
speed are so readily available and
so cheap that the experimenting ap-
proach may be causing us problems;
it may encourage programmers to be
lazy and that is never a good thing.
When modern IDEs allow us to
build something that works very
quickly and modern debuggers allow
us to execute it before our eyes in real
time there is a strong temptation to
design and program by trial and error.
Programs can be patched together as
a sequence of ad hoc amendments to
an initially weak and ill-considered
design. Once the program seems to
work, it may be bundled with other
programs similarly designed. Systems
built this way do not work very well,
are difficult to understand, and are
hard to maintain.
Experimenting and Thinking are
Different. Experimenting tends to be
situational and instance-driven. It is
highly influenced by our initial (and
necessarily imperfect) understand-
ing or simply by how the program was
first thrown together. Experimenting
also encourages understanding-in-the-
small since the focus is usually to more
and more detail to try to somehow
make this program work.
Thinking tends to be more contex-
tual. Using it, we build mental models
that allow understanding of the in-
modern systems
development
environments
are just that:
environments.
Calendar
of Events
October 18–20
11th acm/IEEE International
conference on formal methods
and models for codesign,
Portland, Or,
Sponsored: SIGDa, SIGBED,
contact: fei Xie,
Email: xie@cs.pdx.edu
October 21–23
The 15th International acm
SIGaccESS conference on
computers and accessibility,
Bellevue, Wa,
Sponsored: SIGaccESS,
contact: clayton Lewis,
Email: clayton.lewis@colorado.
edu,
Phone: 303-492-1592
October 21–25
acm multimedia conference,
Barcelona, Spain,
Sponsored: SIGmm,
contact: niculae Sebe,
Email: sebe@disi.unitn.it
October 23–25
Internet measurement
conference,
Barcelona, Spain,
Sponsored: SIGcOmm,
SIGmETrIcS,
contact: Konstantina
Papgiannaki,
Email: dina@tid.es
October 25–31
conference on Systems,
Programming, and
applications: Software for
humanity,
Indianapolis, In,
Sponsored: SIGPLan,
contact: antony L. hosking,
Email: hosking@cs.purdue.edu,
Phone: 765-494-6001
October 26–31
conference on Systems,
Programming, and
applications: Software
for humanity,
Indianapolis, In,
Sponsored: SIGPLan,
contact: antony L. hosking,
Email: antony.hosking@gmail.
com
October 26–28
Generative Programming:
concepts and Experiences,
Indianapolis, In,
Sponsored: SIGPLan,
contact: Jaakko Jarvi,
Email: jarvi@cs.tamu.edu