Fred Koschara - My official personal Web page

The Internet Home of

Fred Koschara

software dev

On “prototype” code development

Aug. 22, 2020, under philosophy, software dev

In many years of consulting, I’ve seen a lot of projects developed with the philosophy of “Don’t worry about [comments][readable code][proper variable names][documentation][error handling][optimization][(your favorite corner to cut here)] because this is just a prototype – we’ll fix those things when we write the production code.” In 100% of those cases, when the prototype was reasonably close to working, it got shipped: The “prototype” became the production code, errors, shortcomings and all. Maintenance, updates and improvements became nightmares, often leading to complete failure of what could have been a great product. Trying to avoid those problems feeds into my OCD tendencies, and when I see a comment like “we’ll write another [CR] to fix it” I tend to balk because I know the rewrite will never happen. Furthermore, when a future developer is called on to fix a bug or develop a new feature, they’re going to be “strongly” discouraged from making any changes beyond their immediate effort, even if renaming variables would make the code more readable when they discovered “flag” is “page_type” or “std” means “start_date” instead of “standard” etc. Having an understandable, well documented interface from the beginning is a LOT more important than making all of the internal variables recognizable. “Cosmetic changes” often look a lot less trivial when you realize that the lifetime cost of code maintenance is generally ten times what it cost for a program to be written initially.

I recognize that I have to reign in my OCD to let development proceed. However, when a developer asks someone to review their code, they need to recognize the reviewer is looking at it from a different perspective than they are. If a reviewer doesn’t understand something, it could either be an error or a misunderstanding. When a misunderstanding is encountered, commenting on a change request doesn’t help the next person reading the code, and adding a comment to the code at this point isn’t a lot of effort. It will, though, make the code more maintainable – it reduces the maintenance cost. Also, if a native English speaker hands a foreign born developer a well written docstring that clarifies a point of confusion, it’s not just courteous to use it: You’re not going to break anything by putting the brakes on for a moment and push one more patch set.


 Digg  Facebook  StumbleUpon  Technorati 
Leave a Comment more...

HumanMathTest, an open source PHP class

Sep. 24, 2018, under software dev, Web dev

HumanMathTest illustration

I’ve published my first contribution to the FOSS community on github: HumanMathTest implements a math test ‘bot deterrent PHP class for use in online forms.

This class is used to create an image to be included in an online form that shows a simple math test the visitor must solve when submitting the form. The operands and operation are stored in the $_SESSION data for the page. After submitting the form, the visitor’s answer is checked by calling the verify() method to compare their entry vs. the session data. If an error is found, the form submission should be rejected.

The demo page illustrates many of the options available, and includes a link to download the fully commented source code, including that of the demo and example pages.


To support my work, please buy a pre-publication copy of Race To Space. For more info about the project, see the Race To Space site, subscribe there to be kept abreast of its progress.

We are going to run out of oil. Before that happens, we MUST have a replacement source of energy and feed stock for our civilization that has become so dependent on plastic. The time to act is NOW!! Please visit to help build a solution.

 Digg  Facebook  StumbleUpon  Technorati 
Leave a Comment more...

Site Features