If you are reading this sentence on the website, let me put this lightly:
You are soooo Web 1.0 – do try to keep up.

Seriously effiecient developers do not go hunting for new information, they use RSS to have it delivered. Here are some videos and links for both the RSS beginner and the feed reading veterans:

Beginners

Veterans

Note: There is no ill will towards Roger, he just hit a hot button.

While walking the dog, I listened to the .NET Rocks! episode with Roger Sessions on Enterprise Architecture. I expected the episode to be about enterprise level problems such as scalability and durability (and all the other -ilities). Instead Roger decided to pretentiously talk about his definition of the enterprise architect role. To paraphrase:

Right now, most businesses are split into two camps, the developers (technologists) and the business analyst. Companies think having two camps specialized is a good idea, but it is not…

The role of the enterprise architect is to understand the problem domain regardless if it is small organization or large corporation. It is a marriage between technology and business…

OK, timeout.

While I understand what he is attempting to say, and I agree that the separation of camps needs to blend [into the proposed marriage] for correct software to be built, there are a number of things wrong with this statement and a majority of this interview.

First off, please do not slap the word enterprise in front of any title unless you are specifically working on enterprise level problems. Using the terms enterprise and small organization in the same sentence is an oxymoron. If your job is load balancing the MySpace web farms then you may have the ‘enterprise’ moniker.

Second, attempting to understand your customers’ business domain does not bestow you the architect title because it is not exclusively an architect activity. I rarely meet a developer that has blindly developed off of a requirements document. Normally, the opposite occurs and passionate developers believe they understand the problem domain better than the client (which they promptly need to be reminded that this is not the case).

What I found most hypocritical about his architectural perspective was while advocating the a needed high level union of business and technology, he divided the technological camp by separating the roles of architect and developers. Developers are the ones doing the implementation, should we not be teaching them to learn more about the business domain? If we are segregating the technologists that know the business domain and those that do not, are we not just creating knowledge silos?

Too often I see the title architect incorrectly used for project managers with no technical skills or senior developers with no people skills. And now, I see the title enterprise architect being used out of context. When titles are misappropriated they start to lose meaning. As a result, the wrong people are placed in the wrong positions causing poor decisions.

In my mind, the architect role is about being the strongest team player, fluent in both the proposed technology but also the problem domain, but no more important than the single developer. The only difference between the architect and developer is the different altitude at which the problem is viewed.

Update: I mistakenly said David Hayden earlier but it was a recording with Roger Sessions. Sorry Dave!

Incorrect task prioritizing by clients and product managers can have a devastating affect on project success. At the end of your deadline, if core functionality has not been delivered the project will be declared a failure. How are you to know what is core functionality when all tasks are marked at the highest priority? We have to remember that tasks are managed by sequenced lists and not a single number.

For example, this is not a priority list:

Non-sequential task management is the equivalent of having a community bucket of uncompleted tasks. This is dangerous because it is easier for feature creep to occur. After all, another drop in the bucket never hurt anything…

Additionally, the above example is a good indication that your client or manager does not understand which tasks will prove the hardest to implement. As a result, clients will over-prioritize tasks that are ‘fresh in their head’ or are tangible such as UI modifications and bug reports.

Instead here is a better one:

So what can the common developer do to combat weak priority sheets?

Don’t ask, demand that you receive a sequentially ordered task list that is updated daily or weekly. A common manager response to this demand is “I don’t have time to do that!”. Really? You don’t have time to manage your people? That response is a sign of laziness or incompetence. It is their job to give you clear direction so you can be a time efficient developer.

Another rule that you must enforce is that all new ideas must be added to the bottom of the list. In an agile world the motto ’embrace change’ is great, but it is very common for clients to focus on immediate needs thus forgetting about the original core requirements. If left unmanaged clients will concentrate massive amounts of your time and budget on immediate non-essential items leaving you delivering late when the core requirements are left to be done.

Correctly ordered tasks can help you become a more efficient developer. They will give you focus on uncompleted tasks and insight to what is important to the client. Don’t be shy to share this post to your client or manager, they appreciate feedback on how to manage your time more efficiently. Your time is their money.