DST is the root rule of which DoTheSimplestThingThatCouldPossiblyWork is the specialized rule for source code polishing.
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...
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?
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:
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 $internalFileor import the appropriate tool from somewhere else:
rsync -tu $externalFile $internalFileor maybe just read the file from the external directory in the first place.
However, that's not the point of the anecdote.
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