Actual vs. Perceived Progress

When you spend all your time at a "low altitude" elbow-deep in code (or similar deep effort), it's easy to lose site of the difference between actual progress and perceived progress. External stakeholders are often only  concerned with perceiving progress, not measuring ever little detail of actual progress.  And in many cases, it doesn't matter how much actual progress you've made if the critical stakeholders can't SEE it -- even if what they see is completely trivial and/or simplified. In fact, oftentimes the more trivial the indicator the better off you are. Simple visual indicators are the best indicators of progress, especially when the individual components to progress are complex.

For instance, check out this simple visual of an evolutionary algorithm evolving the design of a car (in Flash) to traverse the landscape without the red circles touching the ground. It's a simple visual demonstrating what I'd guess to be a complex set of code. (Evolutionary algorithms are optimization algorithms designed to evolve/mutate on their own, using mechanisms inspired by biological evolution: reproduction, mutation, recombination, and selection.)
In business, one thing you can count on is that everyone is extremely busy. Therefore, it's important to apply the fruits of your efforts to visual metaphor, so that stakeholders (investors, customers, partners, etc.) can empirically see their progress without even caring about how it was done. For board meetings, they're called KPIs (key performance indicators). It gets harder though when software engineers and business people need to communicate. This is why I think it's so important for engineers to learn to SHOW their progress, instead of simply achieve progress. No one else is going to care what you did or how you did it, until/unless you can demonstrate it. The perception of progress, therefore, is much more important than the actual progress.

Comments

[Fraley]

Engineers are trained in a rigorous, disciplined process to solve problems by rejecting perceived "truths" through the verification of assumptions via analytical tools (statistics) and experimentation. The value of the solution should market itself, to marginalize the value compromises the methodology, compromises the engineer.

[Jordan Mitchell]

Kevin, the value of the solution should not be only realized by the engineer who created it. It's important for them to show/demonstrate the value to others.

For example, an engineer tasked with reducing wind resistance in a vehicle design should not deliver a formula or design (the solution) and call it done. He/she should demonstrate the decreased wind resistance.