Do Simple Things

DST is the root rule of which DoTheSimplestThingThatCouldPossiblyWork is the specialized rule for source code polishing.

Spiderman does not walk up to an ATM and thwip web strands at it just to get his money out.
Superman does not reverse time just because he bit his tongue.

You are a programmer, and that means you are very smart and capable of quite complex things. Don't do them. Keep your true identity a secret and your tricks up your sleeve. Learn to use your powers for good. Be SimpleMinded: just solve the task at hand, simply.

As I try to tell programmers who work with me: "There's a fine line between fishing and standing on the shore looking like an idiot." -- Steven Wright

The LazyProgrammer does not use "clever" code because everyone who ever reads it or tries to change it will have to be just as clever, every time. -- RichardCHaven

A programmer implemented some very simple reports using memory mapped file technology. It was really cool; one could format data on each report page by manipulating CeeLanguage character pointers. But...

The code was kinda complex and obscure.
Doing "tail -f" on the output file, as it was being produced, displayed nothing but pages and pages of empty lines... because tail would read the pages before the writer finished formatting them and happened to flush the dirty pages.
It was almost impossible to eliminate trailing spaces from lines.

It was the trailing spaces that killed us: These were big reports, and fully 2/3 of the characters in each report file were meaningless space characters... AT THE ENDS OF LINES. Nightly cycles kept failing because our print queues would run out of disk space. Customers called and complained because their serial printers printed those reports more slowly than others.

So I changed the program to use CeeLanguage/UnixOs FILE streams. It was a simple change, as each report had only page headers every N lines, and one-to-one printing of records as lines. Problems solved.

Lesson learned: Why use memory mapped files, when all you really need to do is open a stream and write some data to it?

-- JeffGrigg

What about ComplexityIsBugs?

Another way to see this is if you did simple things first and those did not work well, then you should do the simplest thing in the rest of more complicated ones, and like this recursively to the infinitum... -- ManuelVidaurre

Person A was writing a CeeLanguage program that was to copy a data reference file from an external directory into the main data directory of his application only if the imported file would be more recent than the file currently in the main data directory. He worked 6 hours on the thing because of difficulties with file date comparisons and testing.

Person B solved the problem in 30 minutes:

5 minutes listening to Person A and looking at the code.
5 minutes implementing the solution (just use "make") and testing it, for test's sake, with touched files.
20 minutes convincing Person A that the solution was OK.
- No, "make" was NotInventedHere; so what?
- Yes, "make" was a "system tool"; so what?
- and so on.

Sometimes simple things hurt people.

It would require maybe 5-10 lines of nicely formatted CeeLanguage code to call stat() on two files and compare the timestamps of each (since "make" is available, I assume this is on a UnixOS system). Maybe 10 more lines of CeePreprocessor goo if it had to be portable to non-PosixStandard systems. I can't imagine what problem Guy A was having with that task, other than possibly having never used Unix before (which seems likely if he's writing a C program to compare and copy files).

Make programs supplied with some systems are sufficiently buggy that they cannot always compare the timestamps on two files and figure out which is newer correctly (sad, but true). Make itself has complex and sometimes surprising behavior which tends to appear only during disasters. For example, if the copy of the new file failed, you probably will have no data file in the main directory at all, or you'll have an incorrect file with a newer timestamp (so it won't be updated if you repeat make again).

It does take two or three lines of code on a Unix system to update a file correctly, assuming you have the appropriate tools:

 #!/bin/bash
 rm -f $internalFile.tmp
 # Note: if your 'test' ('[') program does not implement '-nt'
 # ("newer than"), then write the equivalent five line C program,
 # and use that program instead.
 # If externalFile newer than internalFile, make a copy of the file
 # and (iff the copy is successful) replace the application data file.
 [ $externalFile -nt $internalFile ] && cp $externalFile $internalFile.tmp &&
  mv -f $internalFile.tmp $internalFile

or import the appropriate tool from somewhere else:

 rsync -tu $externalFile $internalFile

or maybe just read the file from the external directory in the first place.

However, that's not the point of the anecdote.

Superman does not reverse time just because he bit his tongue.

I'll reverse the time if I bit my tongue off; I think it's hard to live without a tongue, you know.

If Superman bit his tongue, would it hurt? His teeth or his tongue? Think about it...

See also TheBestIsTheEnemyOfTheGood

DoSimpleThings is a very general principle that is a good warming up technique for starting any kind of projects that develop objects or processes in the virtual or real world. We apply it to ExtremeOpenBusiness by actually creating real life examples, who are the building stones of PairDeveloping, UserStories, UseCases, ConstantTests?, etc., bottom-up, incrementally developing/adapting the theory/software in the social setting as an open fiest. -- FridemarPache

CategorySimplification