Jeff's Blog

In the ancient days of high school proficiency exams, I found myself humbled. It was shown to me in starkly clear terms that I had no natural aptitude for the art of creating written instructions. I tried and failed many times to give passable directions to cover the ~500 yards from the high school to my parents' house. Granted I have no idea upon what criteria my instructions were being judge, only that they were deemed inadequate.

This was a hard pill for me to swallow. Until that point I hadn't failed at anything I'd tried to do. In part I know I failed because I thought the task beneath me, and didn't take the opinions of whomever had the joy of grading my writings seriously. But I also did discover a very real limitation in how I interacted with other people.

When I attempt to communicate an idea, task or concept to anyone I usually end up making some assumptions about what the person already knows. This can be a good thing as it might save time and effort, but it can also be a barrier to effective communication. So have I reformed my disjunctive ways? Well if you've read this, you'll be right along with me when I say, probably not. I make every attempt to overcome the nasty habit of assuming shared context when there may be none, but in my most human of moments I falter and make broad leaps of faith to the peril of my intent.

That low bar set, this is a course set of directions that I try to follow when examining software as an abstract ideal.

Observation:

The primary goal of software, in the purist sense, is to concatenate to disparate points. For instance; the bringing together of a thought I wish to express, and the comprehension of that thought by individuals to whom I express it, can be concatenated through the use of software. One of the very nice things about software is that it can often mirror a very well known pattern. Software that is intended to help facilitate this type of communication should at the very least be as effective as simply speaking to each of those individuals. Tangible measurements like efficiency and comprehension can help establish a firm baseline to which any subsequently created software can be measured.

Another example would be software that makes graphs for reporting purposes. One could observe the functionality of other software applications, or even non software analysis tools like an abacus. What does an abacus do well, how does its interface help track and inform, and what proficiencies are required to interpret its data... While this certainly could be taken to an extreme you would likely be surprised at how much applicable information can be garnered from observing interactions with everyday articles that provide information to the user

Observations can be encoded as bounding requirements, or tolerances. This allows the software to be checked against a understood set of functionality, and improves its likelihood of fulfilling its intended purpose.

Description:

This is the codifying of observation, such as stating that the color differentiation and grouping found on an abacus facilitates faster uptake of information. Using this you can test similar grouping methodologies to present information relative to graphs. Having this type of accepted placeholder can help validate even the most obvious of requirements, such as using an appropriate color scheme in the presentation of a pie chart.

Description can be thought of as the developer axioms; these are the principals to which each testable piece of functionality should be checked.

Prediction:

This is the first step in construction of software. Predictions are the tent poles around which the initial application architecture is stretched. Because the intent of software is to shorten the distance traveled to achieve a desired goal, we can't rely on purely known descriptions. It may be known that grouping like items is an effective method of communication, but there comes a point at which existing models don't hold up, so a set of well defined written predictions about things such as efficiency optimizations, or improved comprehension play a critical role in the verifiability of software.

A prediction about graphs, using the observations and descriptions about grouping might be something like predicting that using semi transparent layers to present users with the ability to quickly overly and compare multiple tracked data sets will improve a user's ability to see, and interpret trends.

Control:

This is both the hardest and most necessary portion of the software development. In some respects this is just the idea of having well defined use cases, both edge and standard, but in other respects this is the impartial evaluation of user experience. Control is the part of the process most focused on undermining the basic predictions of a piece of software, not through disproving them wholesale but by trying to ascertain their completeness.

In the software world this is where the iterative process comes into play. Predictions must be refined to suit the checks placed upon a system by thoroughly exercising its bounds. In many ways this is the prime opportunity for QA to interject its influence before the software piece is allows to degrade based on overzealous iterative thrashing.

Falsifiablity:

This is the most overlooked stage in the development process. In its pure sense it implies the lack of any definitive conclusion, and rather is used to bolster a prediction to the position of most likely to be true by showing the falsehood of other possible predictions. But in software terms this is the use of Occam's razor, where by a testable prediction is verified as a narrow slice of the application. Does the prediction hold true, does it carry with it unnecessary implications that detract from its truthfulness, etc.

For instance using the graphing prediction above, validations can be made that, first alternative methods are not more plausible than the prediction (architecture or methodology) chosen. Second it can be checked against itself for purity to purpose. Lastly it can be checked against the original observations.

This is a very basic outline of how I try to approach problems, of course in practical applications I often make shortcuts, or assumptions like we're all forced to do, but it's nice to have an ideal to look up to and wish that it were so. In the next few posts I'm hoping to present a few concrete examples of how this approach has and hasn't worked for me.