Artful Traceability

When you are in the actual throes of day to day production… after the development is done and you work out most of the bugs… it certainly is convenient to have some sort of end-to-end Traceability. The general concept is that every change in state or activity that has a material financial impact to the company (or its customers) should be traceable back to underlying actions.

The idea is somewhat similar to how an airline keeps track of its design and maintenance records. When a portion of the avionics fails during a landing it sure is nice to look back through the records to see what parts get linked where, and what has changed.

For example, at the end of the month you send an invoice to your customers. Where do the line items on this invoice come from: what atoms of work and activity (from a systems viewpoint) do they represent? Can you trace back from an invoice number back through shipping, fulfillment, ordering, and customer options?

Many time validation is just viewed as comparing the results of production back to the functional specs to make sure all of the business rules got implemented correctly. But validation should also be enabled for ongoing activity in a dynamically changing system, and this requires designing for traceability, from the very start.

Artistic Specialty

To some extent folks adopt their software development specialization depending upon their own skills and tastes: do they feel more comfortable with a broader and lighter background or do they prefer to be deeper and more focused? Managers may also have a strong influence over how employees develop their skills simply by the tone and expectations that they set.

Obviously software development requires some specialization, since the technological complexity and the rate of change in our profession precludes a sole person from spending the time required to be a technical expert at all the myriad skills that span the available range of tools. If you wish to employ an expert a direct corollary will be that you therefore choose a specialist. If you plant a honeysuckle tree, you are going to get hummingbirds: that's the sort of specialist this tree desires.

Selecting specialists for software development presents some challenging issues. Unlike hiring engineers to design cars -- where once the model rolls off the production line the engineers move along to their next project -- hiring engineers for a software project is likely hiring them for the entire life of the system.

In this instance the problem that a manager faces is that quality, job security, and concurrency are in opposition. Asking your staff to specialize may give them greater job security and improve the quality of your operations, but they will lose their awareness of how to incorporate and apply new tools and hence lose their personal marketability.

If you hire a specialist to do the job then the result is going to be somewhat unmaintainable by anyone but that specialist. If you hire a generalist it will be far easier to maintain the resultant system, although the final product may well appear less slick and polished.

Ultimately then who you hire depends upon the "positioning" your company is trying to achieve. Are they looking for a short-lasting expensive best of breed solution? Or something long term, stable, and adequate? What sort of tree exactly are you planting?

Artistic Goals

Developing software is both about balancing competing forces and optimizing numerous goals. Down in the trenches all of this happens within the craft of describing to the computer what to do by using a programming language or development tools, but it is still beneficial to keep in mind at a much higher level what should be the general objectives of /any/ large software system:

+ Validity
Your software must meet its functional requirements

+ Parsimony
Keep it simple, avoid bloatware, use a declarative approach that saves intermediate values

+ Incrementality
Plan from the start to make your software readily extensible by incorporating real-world modeling

+ Perspicuity
Strive for clarity and aesthetics; make both the use and the maintainability of your software intuitive

+ Modularity
Remember the advantage of being maintainable and reusable, stay functionally focused, but loosely coupled

+ Resiliency
You need to be tolerant of system faults and provide excellent error recovery

+ Adaptable
Hardware can change -- be flexible for changing environments

+ Performance
Strive to be both efficient and fast

... and yes, these are in precise order of importance.