Goal: Zero  Bugs

As a recent football game started between Michigan State and the University of Wisconsin, the announcer mentioned this game to be a slugfest between a couple of heavyweights. It occurred to me that perhaps, both coaches are focused on allowing the opposition ZERO POINTS. 

A recent Eric Dietrich blog mentions common and weak perspective by many in software: “It’s OK to have bugs.”

Back to football: which coach will tell the team that allowing the opposition to some “some” points is acceptable? This is so perfectly illogical, that no coach would ever start his team off with this step. 

Returning to the weak-kneed software development managers where it’s OK to have bugs. Where and what is acceptable? Do you understand how difficult it is to define this mushy area? All you need on your team is “Wally” from Dilbert to start poking holes in the grand plan and productivity, quality and moral begins the slide… In very little time the quality is low and the team culture is almost irrecoverably beyond salvaging. 

The converse option: having a zero defect culture gives direction and motivation. Zero defects is  hard to achieve since there are so many vectors to pursue. Pick one; make some progress; pick another and so on. This would give team members to contribute on many areas, which provides each member an opportunity to contribute in their area of expertise. You know, punters have different skills than linebackers and so on. 

So then, it’s inconceivable that a coach would spot the opposition any points. Why would we accept the same from software?

Goal: Zero  Bugs

Really Bad Functional Programming

Sometimes one ends up doing functional programming without being aware of it. Having entered that space, it’s easy to fall into complex logic traps that can be difficult to work through.

As an example, lets consider a Windows MSI installation script. Nearing the end of the install process the MSI “InstallFinalize” command is executed. An installer script may then have many “custom actions” that follow. These actions typically have conditions that govern execution.

For example, there may be need to restore prior settings if this is an upgrade. Or there may be a need to install default templates and so on.

What can happen over time is that custom action A is created, then B, C… ‘A’ may be for for an upgrade, ‘B’ for new install, ‘C’ for a new install of version 10.1 templates… I’ve seen conditions such as:

NOT INSTALLED AND &SERVER=3 OR REMOVE<>”ALL” AND &SERVER=3 AND OLDPRODUCTS

or in other words: C1 & C2 | C3 &C2 & C4

This is an actual condition set, probably not well done.

Also, I’ve seen action ‘D’ with condition C1 immediately followed by action ‘E’ with the same condition. Or action ‘F’ with a non-matching condition between ‘D’ & ‘E’.

When this collection of actions & conditions approaches about a dozen, it’s very easy to get lost. This is clearly technical debt that needs refactoring. When a series of actions are called with the same conditions, consolidating into one action reduces opportunities for error.

If you’re using an installer authoring tool such as InstallShield, there may be out-of-the box custom actions that are small & focused. If one isn’t careful, the installer can end up with several calls to custom action X with conditions to match each install use case. Now add many more custom actions with the same condition set and you’ll end up in this quagmire.

I don’t think it makes sense to offer a solution; rather be aware of the overall long-term direction.

Really Bad Functional Programming

IDE Text Editor Plug-ins

Tool vendor’s often offer their own “integrated development environments” (IDE) as a productivity enhancement. Many times, these are indeed a big part of their value proposition and they fit that purpose quite well.

There is one segment of IDE’s that should be delegated to the free market: text editors.

As an example, I’m familiar with InstallShield, a product that creates installers for Windows applications. InstallShield offers the ability to create custom scripts. This scripting language is high-level, but supports local variables, functions, function returns, etc.

The InstallShield scripting editor is weak. Many IDE’s offer editor plug-in’s that allow common editor function such as a VI interface. Developer productivity is enhanced as common functions remain at your fingers!

Given that many other IDE’s have successfully solved the editor plug-in problem, the problem is no longer a moon-launch. A custom IDE text editor is certainly no longer a value-add proposition. It’s just time to out-source this to the free market: open source or otherwise.

Developers should consider editor plug-ins during IDE evaluation also.

IDE Text Editor Plug-ins