Common Error Sources Between Chair & Keyboard
The following list is derived from personal experience with what I call Ad-Hoc Programming. Appropriate methodology and well-defined processes are usually applied to "real projects". But how do programmers handle their scripting on the spur of the moment? How do they approach short-term projects? And how do they produce scripts and programmes for their own, IT internal, use? Even good programmers tend to "just do" - often without thinking any further. This is when most of the mistakes described in this article happen. Unfortunately this does not mean that they don't appear in (the sub tasks of) larger projects.
Error 0x00: Jumping the Gun
It is incredible how often the first line of code is produced before the task and the approach are defined. Justifications are "this is not a fully blown-up project" or "this is just a PoC". The idea is that some software related activity needs no methodology nor preparation.
Recommendation to the insistent Ad-Hoc Hacker:
Even if your
SDLC is based on words like rapid
or agile, the immediate, eager production of code is doomed.
Even if the expected amount of work is low, the first line of code
should not be typed before the programmer has at least a page of text
and a pencil drawing describing the requirements, the solution,
the design, the resources, and a rough schedule.
Error 0x01: „Self-Explanatory Code”
The idea that looking at the code explains its purpose and how it works might be at most a white lie, and at worst a horrific philosophy. Do we expect a nervous administrator during an incident to understand our preferred shell or scripting language? Will the person in need find out what other cronjobs and scripts are involved from the pure code? Reverse engineering is big fun, but not under time pressure. Leaving system administration and incidents aside: If you are to extend for example a Java application you will, unless system and API documentation is available, end up with spaghetti code - even when you are the author of the original (older) application.
Error 0x02: Belated Documentation
"Once we get it to work we will care about the documentation."
Did you ever try to document classes, methods, or other code sections
before writing the code itself? This keeps you aware of what
you are actually trying to achieve with the code. Writing down what the
code will do moves the programming task to 40% completeness.
Plus: Writing documentation beforehand often reveals deficiencies and
contraditions in the basic approach.
Using tools like Javadoc, RDoc, etc. makes it a great fun to re-use
code.
Conclusion: There is nothing wrong with first thinking, then
describing, and then finally writing programme code.
Error 0x03: Belated Testing
Functions and methods are to be tested while writing them.
And when the module or class is complete, it does not hurt
to test it systematically. Unit testing is a positive addiction.
Once used to it you can't get enough of screen output like:
0 failures, 0 errors, 0 skips
Error 0x04: Inconsistency for Pragmatism
A programmer should not practise too much pragmatism
in the general meaning of the word, but rather learn it
from Pragmatic Programmers like Thomas & Hunt.
The
Broken‑Windows‑Theorie
does apply to software:
Violating the consistent design of a software by one single
exception or "hack" will cause the software to
degenerate sooner or later. The "only one single exception"
may look like the work of a solution-oriented expert who
maintains deadlines, but usually it is the turning point
to an unmaintainable Software.
Conclusion: Stay clean! Always.
Error 0x05: Skipping Brakes
In a mood of exaltation and flow it seems hard, but nevertheless:
Breaks should happen before tiredness occurs. Leaving the
work place for a moment pays back in new ideas, rethinking, and
sometimes conclusions like being on the wrong track.
By the way:
Distance looking is good for your eyesight, be it just a look out
of the window or a real
eye exercises.
Error 0x06: Stubborn Searching for Solutions
It may happen that you work past midnight and the last break, drink
or sandwich was 8 hours ago. And you may still see no progress at all
in getting this nasty problem solved. You give up and on the way home,
while Led Zepelin is rocking from your car stereo you recognize -
without even wanting to think about work - that you had been blocked
by a fundamental reasoning error. The next morning you solve the
problem within 20 minutes.
Conclusion: Sometimes you need to just all it a day.