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.