Eventual Correctness

Have you ever heard the term Directional Correctness or perhaps Directionally Correct? In the software business it is often used for when the concepts, functionality or usefulness of a thing is understood or apparent, even when there are details or bugs that prohibit full acceptance.

If you are building a form for the user to input data, having all the form elements and the submit button without any formatting, style, or validation would be considered Directionally Correct.

The process of building something new is often littered with the broken attempts and failed assertions. This is actually one of the driving motivations between Test Driven Development. Good designers use iterative processes to arrive at a great solution, it doesn't just magically appear. Great designers help those around them iterate also.

Have you ever looked back at the end of the day and realized you worked on the same design element the entire day? Have you ever had a user or consumer completely yank the carpet out from under you and realize that all the progress you made wasn't progress at all? A key reason this occurs is because we get too focused on the details too soon in the game. After all, the greatest engineers are perfectionists. It isn't done until it's Right. And that is what trips us up.

As engineers and designers we should foster or sense of elegance and perfection. Just not right away. We need to evolve our solutions, not magically produce them instantly. Produce something ambiguous and generic but somewhat functional. Or at least demonstrative of functionality. Get the users and consumers hand-waving in the general direction. Once you've achieved some agreement on the direction you are taking, then you can start hammering in nails and confirming details.

Besides being able to verify your work with consumers, it is important to delay details for your own benefit as well. The old Forest vs. Trees problems can impact even the most seasoned woodsman. As you implement your vision the details will reveal themselves. The gaps and holes will become obvious and you can address them with precision and prejudice. If you focus on details only after you have verified your directional correctness, they won't move or shift so you can be certain your specific solutions will serve.

It can be hard to iterate, especially with our innate desire for perfection. Iteration is like delayed gratification. You can make it perfect, it will be amazing and elegant. . .eventually.

Absorbing Change

Embracing change is something at which I am usually very adept.

Some might even say that is because I am responsible for most of the change that I see around me. At least on projects. But that isn't fair. I recognize as well as anyone the necessity to stabilize from time to time. To slow the pace at which change is being identified and absorbed into an organization. Many of the processes and much of the effort I exert is designed specifically to assist with the absorption of change; controlling the velocity that change impacts ongoing efforts.

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.
-- Martin Fowler

Sometimes large changes are required. It is natural for individual contributors to get invested in their work and become very attached to their specific deliverables or designs. To my mind, being flexible is a critical component of competence. Without adaptability, your useful as a contributor is minimized and in some cases suspect.

Going beyond the ability to handle change as someone customer-facing is the capability to influence both the speed at which change is introduced to the delivery organization and the expectations of the customers creating that change.

To be a good lead, protect the pace of change you expect from your people. To be a good consultant, manage expectations with your clients about the changes they want to introduce.

Dead Man Walking

Most software projects fail. The statistics are varied but a pretty fair sweeping generalization of all the research would indicate that most software projects fail.

If most of them fail, then it is logical to surmise that at any point you care to examine them, the majority will be dying. Sure, they might hang on. They might be fighting horribly and even look like they have a chance to succeed. But most of them fail. They die.

If you were out hiking in the woods and came upon a man mauled by a bear and he was shouting incomprehensibly and swearing like a sailor what would be your reaction? A helpful or trained person might run over and assess the situation. They would question and listen, they might possibly poke or prod. The answers might be meaningful or simply swearing or more realistically just Pain, Pain, Pain! The conversation would get more succinct, more direct. Answer me or I can't help you! Neither would stop to criticize poor grammar or discuss the appropriateness of language. They would listen to the content and contribute to the sharing of information. Presumably, they both want to save the dying man.

As the situation progresses, the person trying to assist the dying man would make decisions based on what they independently observe is hurting, by which movement brings the loudest screams, or by which open wound is bleeding most profusely. Because the priority of the situation demands it, they would ignore the swearing and the sweat and the blood. If the wounded soul gets out of control, they might sedate them if possible, or simply slap them to snap them back to reality and focus. Having been in similar situations, I can tell you there is shouting and flailing galore. The communication will be rough, it will be high velocity, and it will rarely be diplomatic or couched in rhetoric and hyperbole. After all, someone is dying.

If you are starting a new project, chances are it is already dying. Will you watch politely while it bleeds out? Will you bind the hands of those who can set the bones or knit the flesh? When a person with their hands in the gaping head wound says "Move!", don't demand they say Please. Remember, your project is dying.

We Have a Piper Down!

Yesterday I was attempting to customize my Flickr feed so that my Twitter posts would be more readable and I used Yahoo! Pipes to make it all happen.

The above buzzword-laden sentence is an example of flurry of intertwined concepts and technology that is rapidly becoming a cornerstone of my life. And I love it!

Yahoo! Pipes is very cool technology. A stunning example of driving adoption through value-added services that are intangibly monetized. (What a friggin' mouthful.) What I mean by that is that Yahoo! Is providing this service free of cost and what they are realizing is a slew of benefits that don't have direct immediate financial gains. The long-term gains of developer loyalty and driving adoption of their related services (Security, Mail, Blog, Reader, Calendar, etc.) will pay off in spades if they continue this trend.

During the early years of Windows there was the Win32 War. Some people thought 16-bit processing was better, others wanted 32-bit. Apple as a platform or Windows or OS2 or ? It became apparent that the way to win platform adoption was by having the most applications for that platform. You get the most applications by making it as easy as possible for developers to create those applications. This is the same today when the "platform" is a service you want used, and the "developer" is a consumer who points and clicks and publishes feeds.

The thing I found most intriguing about the Yahoo! Pipes offering is how easy they've made it to leverage all the outstanding work that others have created. Not only is there a massive wealth of capabilities directly in the tool, but the ability to clone other Pipes means the learning curve and information sharing is ridiculously easy. Whoever is running the show over there needs a serious raise, and a bigger budget. More of this and better press would put Yahoo! as a platform much more seriously in the running.