Rage Dictionary: essential complexity

Essential complexity is the inherent complexity of any solution to a problem after paring away the particulars of how the solution is implemented by some engineering means.  A measure of the simplicity and efficiency of a candidate solution is how well it solves the entire problem using as few constructs as possible.

"Consider the complexity on a scale from 1 to Java..." --one of my software engineers

In programming terms, essential complexity of a task such as "Determine whether a list contains duplicate elements" dictates in the general case that you must examine each pair of elements at least once.  There is the question of loop optimization, to be sure, but essential complexity looks at the problem space and the algorithm, while the remaining complexity is taken up with the mechanics of the data structure, its iterators, and whatever syntactical framework is required.

Programs therefore commit one of two converse errors.  Incorrect programs often oversimplify the problem and miss corner cases.  Corner cases are part of the essential complexity of the problem; handling them elegantly and efficiently is part of the task.

But more often programmers err in addressing parasitic or imaginary requirements  through a plethora of poorly-managed, strung-together components, an overgeneralized framework, or other elements that add complexity to the program solution well above and beyond what is required to solve the problem.

Rage Dictionary: tracking development

Tracking development is a special case of recurring engineering in which the integration of an outside (typically third-party) application or code base comonent requires non-trivial revision in a glue layer or the component code itself every time the foreign component is revised.  It should be avoided for several reasons.

• Recurring engineering generally exceeds the one-time cost of proper up-front design over the life of the product.
• It complicates component upgrades and reduces the incentive to stay current.
• Pollution of third-party code bases may introduce defects for which the third-party vendor's test program has no test.
• It is a common omission in workflow when a project is transfered among developers.
• End users who know the component is included may be surprised when it behaves different from how they expect.

Tracking development is not merely coping with changes introduced in newer versions of a foreign component.  That is ordinary software refreshment and occurs on an ad hoc basis according to the component's development plan.  Instead, tracking development denotes modifications made to the foreign component itself for inter-operation with the host system, such as adding local options to a configuration file by means of modifying the parsing function.  These modifications must be repeated for every release of the component.

Techniques for avoiding the burden of tracking development include (in order of preference)

1. Careful selection of the foreign component, and limiting interaction with it to its documented out-of-the-box behavior.
2. Collaboration with the component vendor to support the needed interaction.
3. Wrappers and glue layers that translate between the component's out-of-the-box behavior and the needed behavior.
4. Expression code-level modifications as patch(1) files.

A bit of geek humor

Python's (not necessarily Monty) Meaning of Life

The Right Way to Get Support

Forwarded to me by a front-line customer support representative:

To Hosting Provider: [redacted]

re: Domain [redacted]

My SQL DB has decided that it will pretend to be invisible. I have tried to repair, update, and upgrade to no avail. Besides playing it comfort music and preparing it grilled cheese sandwiches and tomato soup, I am officially lost. Oh ya, and the Backup in [web panel] won't load... Totally not zesty. Ya dig?

As the senior engineer I deal with escalations of last resort.  By the time a customer's issue reaches me it has already gone through two tiers of support, and I have nowhere to escalate it further.  Sadly, unlike the Supreme Court, I can't just let stand the lower court's decision.  I have to fix it.

Software developers of all ranks hate escalated support requests more than an empty soda machine.  In practical terms esclations wreck a well-planned day since they typically have to be deal with before going on to forward-looking work -- and production schedules don't yield.  In softer, fuzzier terms, software developers take a hit to morale every time their software doesn't work as planned, or some user has failed to grok its obvious genius.

The excerpt above is how you blow past all that and get good service.  The user has a point.  He's tried all the "usual stuff" before picking up the phone.  And he tells the representative this, so we know where to start.  But the obvious win is the humor.  It's going to win you top-notch effort from all involved, including the senior engineer who may eventually have to drop what he's doing and investigate your problem.

An approach like this is far and away better than berating the support representative with profanity, telling him how much your business is losing for every second your web site isn't working, demanding to speak to supervisors, etc.  A soft answer turneth away wrath, saith the good book.  In the same vein, a cleverly worded, deferential, entertaining trouble ticket not only turneth away wrath and getteth really good service, it can windeth up immortalized on someone's blog.