Are You Sure?

It is a pretty normal day for me when a friend says they want to accomplish something and yet they have no idea how to go about it. They want to start a business, but aren't sure what kind of business. They want to make more money, but aren't sure how. They want to get certified/learn new technology/become famous/[insert random goal here]. In all cases, they have an ambiguous idea but not a specific agenda.

A man with a watch knows what time it is. A man with two watches is never sure. -- Segal's Law

In our era of The Paradox of Choice, it is the amazing potential we all have to stand on the shoulders of giants and achieve greatness that is most often our downfall.

We have to choose every day as engineers which technologies to support, which languages to learn, which certifications to pursue. We are bombarded with choices for what social networks to participate in, which email system to rely on, and should we use an Mac or PC? Is it IPhone or Windows Mobile?

As an architect, the most valuable thing you can do is be deliberate in your choices. The hard part is being deliberate quickly. Digesting the massive amounts of ambiguity at a breathtaking pace to synthesize answers and clarity as and when they are needed, usually well before the obvious answers have become apparent. If being an architect was just about picking the obvious when it became obvious, then everyone could do it. (Which probably explains why everyone thinks they can do it.)

If you want to get out there and do something, first narrow down what that something might be. Perhaps start by writing down what it isn't. Then start writing down the attributes or identifying characteristics for what it is. If you can describe what the world looks like when you've achieved your goal, you'll be a good way towards deciding what road will get you there.

Or don't.

It's your choice.

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.

Classic isn't Adaptive. Adaptive isn't Agile.

In the world of software development there are many schools of thought on how to go about creating great software. Ignoring the creative side of things such as how you know if software is good, or what solution will meet what business need and so on. Even if you limit the discussion to how you go about implementing a solution once you have identified one, you will still find vastly differing opinions. We call these schools of thought methodologies because they define the method that you use to develop software.

Like all good architects, I too have a method to support my madness when implementing a new solution. My particular approach is thoroughly unique (just like everyone else I suppose ;-)

My particular brand of madness is considered relatively progressive borrowing heavily on the concepts espoused by Agile and Iterative approaches which are fundamentally Adaptive in nature.

The majority of men meet with failure because of their lack of persistence in creating new plans to take the place of those which fail.
--- Napoleon Hill

At the speed in which we are asked to deliver solutions, in an environment in which the business needs remain volatile and the resource allocation continues to be fluid, I feel the only responsible choice in methodology is one that has an adaptive component.

Are you still following a Classic approach? How's that working for you?

This past week I had great opportunities to talk with some charming gentlemen at Microsoft who are working on the next generation of Team Foundation Server and Visual Studio Team System. It was great to see them bringing more adaptive principles into the product. It bodes well for the future.

And for someone who is actively working to solve these challenges now instead of in the future it was very validating to see that our thoughts and approaches were similar. Very validating indeed.