Neo Diem

Azure Adventures

noreply@blogger.com (Tempus Fugate) — Thu, 08 Oct 2009 00:12:00 +0000

If you are going to be using Azure, make sure your SQL Server instance isn't on a compressed drive. Also, running in Windows Advanced Server is much easier than trying to juggle all these pieces on Vista. If, like me, you already have an instance of SQL Server you need to use the DSINIT tool to get storage initialized before trying to run anything. It's not a big deal just use dsinit /sqlinstance:. from the azure sdk bin directory. One trick is to use the period for an unnamed instance. If, like me, you are running Advanced Server, you need to also run Visual Studio in elevated-mode if you plan to debug at all. And who's kidding, you have to debug right? I've been playing with the SQL Azure CTP as well and I see some good things in store. I'll post some more useful learnings as I port more code into the cloud.

Packaging Contracts for Services

noreply@blogger.com (Tempus Fugate) — Tue, 07 Jul 2009 20:50:00 +0000

In working on a green field system recently (green field means it's new from scratch development) the discussion for a series of services turned to the subject of which type of data interaction should be used. Specifically, should the service be designed using message contracts or data contracts?

Since it became clear that the basic inflection points were not well understood, I had to hold an impromptu clinic. After we finished, I wrote down the salient points and turned it into this post.

The first thing to consider when choosing packaging formats is whether the messages need to be conformed. You see, many technologies don't comply with the published contract specifications choosing instead to rely on the lowest level XML serialization for interchange. If these messages already are in use, or you intend to interoperate with a system that has such restrictions, the choice is usually made for you.

If you are playing green field (as in the conversation sparking this post) it helps to understand that data contracts have good portability which makes them widely applicable. Message contracts are less capable and therefore can have less portability .

So the less conformant you are required to be, the more reason to choose data contracts. The more conformant your requirements, the more likely you will need message contracts or even base XML serialization.

What's The Hold-up?

noreply@blogger.com (Tempus Fugate) — Wed, 03 Jun 2009 00:07:00 +0000

You know you are having one of those days when you're writing code like this:

select top 5
(select substring(text, (statement_start_offset / 2 ) + 1, ((case when statement_end_offset = -1 then len(convert(nvarchar(max),text)) * 2 else statement_end_offset end ) - statement_start_offset ) / 2 )
from sys.dm_exec_sql_text(sql_handle) ) AS statement
,last_worker_time
,total_worker_time
,last_elapsed_time
,total_elapsed_time
,execution_count
from sys.dm_exec_query_stats
order by last_elapsed_time desc

This technique of pulling from query stats is great for finding those nasty performing culprits, especially in environments when you can't just attach a profiler.

In case you were wondering, I use queries like this instead of sp_who or sp_who2 because it's specifically grabbing the statement that is executing not just the batch.

Cyclomatic Complexity

noreply@blogger.com (Tempus Fugate) — Thu, 12 Feb 2009 20:59:00 +0000

Much of my day is spent convincing engineers that there are simpler ways of implementing their designs. Much of the rest is convincing executives and managers that what they want isn't simple at all.

Invariably some little hot-head tries to argue with me that implementing a general case is more complicated than a special optimized case. If the punk in question has cracked a book they'll likely bring up some metric like Cyclomatic Complexity.

Thomas McCabe socialized this metric in the 70's as a mechanism for predicting where code would have future maintain problems. It's often thrown into the blender when people are trying to construct qualitative measures for code quality. Here's the formal equation:

CC = E - N + P

E = number of edges N = number of nodes P = number of connections or exits

It can be hard to see how equations like this apply to code so let me say it a different way: Cyclomatic Complexity represents the number of code paths through a section code.

How do you count the code paths? Start with one for the entry into the code, and add one more for every decision point. Decision points are the control of flow statements like If…Then…Else or Switch. The CC for the following snippet is three (3).

public int adjustRange( int rangePrimary ) {
bool adjustedValue = 42;
if ( rangePrimary == 6 ) {
adjustedValue = 42;
} else {
adjustedValue = 9;
}
return adjustedValue;
}

This example was really simple but is illustrative of how the CC may be calculated.

So how complex is complex? As with most metrics, the interpretation is very subjective. Since the higher the number, the more complex the code, it stands to reason that code with higher numbers would be more prone to issues. Perhaps bugs because of the logic convolutions, or issues with maintenance because of the number of things impacted by even simple changes. In a sweeping generalization I can say that for my reviews, code with values higher than 20 would be suspect, and higher than 30 would likely not pass.

The important thing is to realize it isn't a measure of quality, just an indicator where better organization or testing might be advisable. Personally, I tend to gauge an engineers competence inversely to the CCs of the code they routinely produce. In my experience, engineers who write better code routinely produce code with low CCs and vice versa.

A Goofball CEO and a Silly Journalist

noreply@blogger.com (Tempus Fugate) — Fri, 06 Feb 2009 18:30:00 +0000

If you run a major international company, you shouldn't be dropping cuss words in public. IMHO.

In a recent article, the SAP co-CEO Leo Apotheker was quoted making some of the dumbest CEO comments I've ever heard. I wonder what how big his *ahem* bonus must be for him to so blatantly disregard common sense.

The follow-on article was equally hilarious. It shows how much pressure the Old Timers are under to stay relevant. Add this to the recent absurdity of the Satyam Scandal and it becomes clear some house cleaning is in order.

I found the most insightful comment in the follow-on to be:

The core of most cost/time overruns stems from CIOs committing to ERP, but middle managers insisting after implementation is already well underway that the software be changed to accommodate legacy business processes rather than the other way around. -- Eric Krangel

Amen, brother.

But wait, it doesn't stop there. You have to read the comments too. Here's my favorite:

Accenture made me rich when we IPO'd it in 2001.
I'm willing to forgive all else.

-- Maurice (commented on the Alley Insider article)

That pretty much sums up how the Bozo Effect is getting worse. I think it's time to go back into retirement. Again.

Or maybe a start-up? Hmmm...

Priming For Performance Testing

noreply@blogger.com (Tempus Fugate) — Fri, 16 Jan 2009 20:16:00 +0000

One of the last few endeavors I've had involved planning for some performance testing of the critical application stack for extremely large volume business. Specifically, they were looking to make some architectural changes because of performance and needed to know which ones to make. Which explains why I was in a room with a bunch of big-wigs yet again explaining why the performance test is more than throwing requests/transactions/load at the system and seeing what breaks.

After quite a bit of round-and-round, it became evident that I had to bring us back to basics and get on the same page. This is hardly new and I find myself often giving impromptu primers on Performance Testing. This posts covers the basics and illustrates a simple example of how to apply them.

Let's get started. . .

When it comes to performance testing, there are two generally accepted types. You can Prove, or you can Predict. These are not equivalent. The names may be self-evident but let me give some quick examples to clarify.

If you are seeking to Prove, you put load on a system and determine that the system can in fact handle the load within set constraints. For example, it handles X requests using only Y memory and Z processing units with Q response time. You know it to be true because you actually did the work. It's not simulated work, there aren't stubs, there is no approximation involved.

If you are seeking to Predict, you put load on the system under constraints in such a way as to understand how the system will react to changes in either load or constraints. For example, the system performed X requests with Q response time utilizing Y memory and Z processing units. Further it performed (X*2) requests with Q response time utilizing (Y*2) memory and Z processing units. Therefore I predict the system can perform (X*3) requests with Q response time utilizing (X*3) memory and Z processing units. Obviously it is never this simple as there are many ways that variables interact, but you get the idea.

As part of the discussion, it became clear that an understanding of the basic math involved would be helpful. Naturally you can't expect a bunch of execs to sit still for a calculus lesson. But it was possible to give them a simple example to demonstrate how complicated even the "simple" vectors can become very quickly. So we walked through using a very simple statistical probability formula to calculate a Poisson distribution for the number of concurrent users.

The simplest form of this generally only uses three variables:

User Population
This is the population or total sample size. Just because there are billions of people in the world, not all of them will be using your application. Hopefully.
Session Length
This is a measure of how long the operation that each user performs. As you can imagine, this one is hard to simplify and in sophisticated models is the quickest to require much more work to derive the real value.
Availability Window
This is a measure of the time range in which the application will be available for use. Usually you want to exclude maintenance windows, or perhaps reduce this to only include normal business hours.

Using these variables, we can create a formula c = (p * s) / A to allow us to find a concurrency distribution.

c = Concurrence
p = User Population
s = Session Length
A = Availability Window

So for example, there are 2000 employees who have access to the portal. Each user spends an average of 7 minutes submitting an expense report. They only do this from work during normal business hours (9am-6pm or 9 hours).

Therefore the likely concurrency is (2000 * 7) / 540 or 26 users in a 7 minute session using the application.

These are of course just numbers by probability, not proof. But it would help you figure out by taking further percentages, what your concurrency expectations might be.

This is really just a small scratch on the surface of a very large topic but it helped to demonstrate how large and complicated it can be. Which is why you should really on expertise and not guesswork. And why things that appear really simple in models like this, typically are not.

A Truth Revealed...

noreply@blogger.com (Tempus Fugate) — Sat, 10 Jan 2009 01:06:00 +0000

If you've done any offshore work, and I do mean really done the work not just been near the work, you know what a house of cards some of the industry players can be. Finally it seems we are getting more details on exactly how messed up this market can get.

Just recently the head of one of the larger organizations, Satyam Computer Services, released a letter detailing the ongoing fraudulent activity that was riddling the corporate books. If you've ever competed against these guys you have invariably asked yourself, "How are they making money?" as they priced you out of a deal with ridiculously low costs. Now you know: They Didn't.

You can read more in the New York Times and elsewhere on the web.

The near term impact means that there will be quite a few companies including GE, GM, Nestle, Caterpillar, Coca-Cola, Microsoft, Pfizer and the US government who will be looking for new IT providers pretty quick. The real downside is that those companies have been budgeting for years using unrealistic offshore rates. Shifting that burden to more realistic rate schedules on short notice could be quite a jolt to many corporate bottom-lines. The ripple effect is that it will take money away from advancements, growth and sustainability just when we need this type of spending the most.

It's a fun thing to be able to say "I told you so." when you find out a company who consistently undercut the market in extremely detrimental ways finally comes clean. Unfortunately, it's not very satisfying. You see, we have the same experience in many markets and segments of our economy. Rather than paying what something should be worth and recognizing that money spent is money that feeds our nation, we continually strive to cut costs and do things on the cheap. Commoditizing high-tech doesn't help anyone, anywhere. Not in this country, and not in the country you are moving the work too. And besides not helping in the short-term, the long-term effects of depressed rate structures create unrealistic expectations and remove incentives for growth. They have ripple effects throughout the economies and cultures involved and can do irreversible damage when reality finally does come crashing down.

This situation is not unlike the consumer credit crisis or the disease that is WalMart. If people think they can pay less, they will. Even if it isn't best for them or anyone in the long-term. In many cases, even if it isn't best for them in the short-term! That's why people spend multiple dollars in gas to drive to a further store and save a few pennies. That's why people buy organic food that has to be shipped from another country to a horrendous environmental detriment instead of recognizing that industrialization is VITAL to a sustainable civilization. But I digress.

In the future, we won't always get such a clear explanation of the full cost of those ludicrous deals we take advantage of every day. Sometimes it isn't just plain-old fraud that's at the root. But there are always costs and impacts and we should try and understand the big picture instead of being naive consumers. Remaining ignorant about the supply and service chains that provide everything we consume and rely on is a surefire way to create an even bigger mess in the future (like we need a bigger one than gas prices?).

Next time you see a deal that seems to good to be true, remember the old adage and realize: It Is.

My Online Eyeballs

noreply@blogger.com (Tempus Fugate) — Mon, 08 Dec 2008 18:57:00 +0000

I'm a huge fan of Fred Wilson. Have been from the first time I ever read his words.

Lately, he's wrote a little something on an area that I generally ignore but had been catching my eye. Specifically, this post was about the challenges and opportunities with online advertising.

Most of the time, I tend to put my energy into learning about and understanding other areas of technology or trends, but lately I've become more interested. This is mostly because I have friends that work in various segments of advertising and those specializing in the online space have had interesting things to say.

One of the great things about Fred is that no matter whether I agree or not, he brings up the salient and pivotal points of the subject matter with precision and elegance. This is how I would want to write if I could write the way I want. Witness:

Analog and digital, it turns out, are polar opposites. Analog has physical costs which lead to scarcity driven business models. Digital has zero marginal cost (or near zero) which leads to ubiquity driven business models.
- from Trading Analog Dollars For Digital Pennies by Fred Wilson

The remainder of the article is a succinct primer proving once again that smart people are in fact out in the world, kicking ass and taking names. And then there are geniuses who take the time to write about it for the rest of us.

What struck me in this discussion is not the conclusion (in any logical progression that's typically the boring part), it was how subtly he separates two behemoths that are often deemed inseparable and treated as such. Too often, I find myself in the discussion with an educated person who is waving theirs hands about the effort it will take to "move more of our advertising to the web". Or some such nonsense. They fail to understand that the basic economics, motivators, and operating principles for digital consumers is completely different. When I listen to a "marketing person" talk about how a platform will have "captive eyeballs" or "impressions" I realize immediately I am talking to someone who doesn't get it.

This was made real in conversation with a buddy of mine recently about some time after Wii Music hit the stores. His introductory comment:

I own a Wii. I love music. How did I not know about this?

Hmm, lets think about this. When I consider his lifestyle it is like many of my friends. He uses Firefox with ad-blocking software, watches tv only online and usually just via netflix streaming, listens to pandora or online music, works from home/coffee shops, and doesn't drive. No wonder it slipped under his radar.

If you want to get his attention (or mine, or most of my friends) you need to leverage the things we do care about and the media we do invest in. Simply running ads on blogs won't find a growing hoard of us. Put that information IN that same blog and then we'll be all over it.

And...I'm Safe.

noreply@blogger.com (Tempus Fugate) — Mon, 01 Dec 2008 21:15:00 +0000

It's good to know that according to the big analyst firms, the key areas I'm focused on are going to continue to be the top spending areas in this down-turned economy.

InfoWorld reported in an article here, about the findings of several big IT analysis firms what are supposed to be the top 5 spending priorities for the next year. Not surprisingly, cloud computing and business optimization were up there.

When the economy isn't doing well, I often get the question about how my business is doing. The great thing about helping companies do business better is that tough times are great motivator in the way that years of plenty are not. Simply put, if they are making lots of money anyway, it's hard to get people to focus on the costs involved. When they aren't making money so easily, all of sudden they are very interested in what things cost.

You can apply this to your own life too. Are you in feast or famine? Should you be making hay while the sun shines, or playing frisbee? Having billable work is no excuse to put off training, writing, and exercise.

Preparing For Multi-site Engagements

noreply@blogger.com (Tempus Fugate) — Fri, 07 Nov 2008 17:21:00 +0000

I've spent quite a bit of time in the last several years living and learning with the challenges of doing multi-site projects. From offshore development where I managed teams operating between the US and India, to near-shore development with teams on both coasts of America, to smaller engagements with 6 people in 3 west coast cities. I've had successes and not a few glorious failures. It's the pitfalls, missteps, and screw ups that helped me learn the most.

Recently, I was asked to give some feedback on the things that have the most impact to new multi-site engagements. This is a pretty common request these days and I've since written down my thoughts so I could present them more consistently. This post is a very succinct summation of the big ticket items.

Naturally, much of this advice would be tailored to the specific circumstances and players, but the items discussed in the post are all generically applicable. If your situation involves working with teams in India or Manila or Slovenia (as examples), you'd want to get some specific tips on dealing with those cultures. This is no different than if you will be working with any of the Native American nations or in Silicon Valley where there are special considerations. Always get the heads up so you can be sensitive to the culture in which you'll be working. But those are for other posts, on with the show.

My personal guide is an ordered list I cheekily refer to as the Four T's. In order of impact they are Trust, Time, Transparency, and Talking. I'll discuss each a little to explain what I mean.

Building and maintaining trust is the single most critical thing that can impact your engagement. It is extremely easy to take this for granted, especially since it seems so obvious. In reality, we rarely address issues of trust head-on in the corporate world, but they become very important when you don't have face-time to rely on in the relationship. Nothing builds trust as fast as personal bonding time, nothing destroys it faster than a lack of transparency. Once trust becomes compromised, every other facet becomes harder and more risky. Without trust, communication become s suspect and morphs from a tool into a weapon.

If you want to earn trust, get some face-time. Obviously, in the real world is best, but lacking that, get on a video chat. You have to be able to read and see body language. You have to find a way to bond and see each other as people not resources. You have to allow everyone to take the measure of everyone else and to fill in the mental picture that they'll remember and substitute into every other conversation regardless of media.

Recognize up front that coordination among parties in different physical locations is inherently going to take more time. It takes more iterations to verify directional correctness, ensure quality, and declare accomplishments. Everything just takes more time. Stop trying to pretend this isn't the case or even to minimize this to act like it won't. Just prepare and plan for the impact, embrace the reality when it occurs, and don't get cocky when things are going smooth and you think you can tighten up.

When it comes to operating transparently, make sure you are delivering messages properly. Any directional messages should be disseminated with the whole team at the same time. When possible, do all messaging to the entire team at once. Then reserve your smaller leadership group for issue resolution and check-pointing. This can feel unwieldy at first, but the dividends it pays in trust will more than make up for it. If you are suffering from any trust issues, this can be the only chance at repairing the damage and pulling the team back together.

Lastly, don't under-estimate the power of Talking. Emails do not carry tone or intent very well. They aren't very transparent so they wear down the trust and are the easiest road to miscommunication. This is not to imply you don't write things down. On the contrary, always follow up your conversations with a written summary of the talking points decisions, action items, etc. But as much as possible carry your meaningful conversations over voice. If you can add the element of your face and body language via video, this is all the better.

These are important things to consider as you move forward but the attitude in which you apply each of them is also critical. Remember that you aren't planning for efficiency, you plan so that you'll recognize the problems that WILL occur and fix them without a total collapse. This is similar to how automobiles are designed. Some years ago, some automobile companies made amazing and powerful engines but you had to take the whole thing apart to change the oil. Other companies came along with designs that weren't as efficient to run, and were a little more expensive to design and build. But the oil change was a simple thing anyone could do for a few dollars. Ultimately the more successful designs were those that made it easiest to deal with the challenges that were certain to arise (changing the oil) as efficiently as possible instead of trying to optimize for performance or build cost.

The last tip I'll offer in this post is about quality and standards. When doing multi-site engagements that involve parallel efforts or multiple work streams, consider separating the oversight for quality or standards enforcement into an isolated group. Leaving the oversight functions within the different operating units allows disparities in enforcement or standards to creep in. This often is construed as unfair advantage or favoritism or something equally nefarious. Left within each group this disparity is pretty unavoidable and is a very subtle disease that can do a lot of damage when left unchecked. Making a distinct group responsible for these functions will help avoid this issue and its variants. It can also serve as a single neck to choke when trouble does arise.

Don't forget that tips like these aren't any use if you don't treat people with respect and act with integrity.

Master Data Management

noreply@blogger.com (Tempus Fugate) — Wed, 30 Jul 2008 19:47:00 +0000

Recently I had the pleasure of discussing with a prospective client the bulky subject of Master Data Management (MDM). In this situation the client was considering a variety of MDM solutions and wanted some specific direction into which technology/vendor to choose from.

Now it is no secret that I tend to favor Microsoft products but in this case the platform already in place was Oracle so naturally, I wanted to give them more general advice instead of just pushing MS MDM.

There are quite a few upfront activities that must be done regardless of which products you are going to use. I've listed some introductory efforts that need to be done earlier in the process and that can be done before production selection.

Governance
To get the ball rolling, you really need to figure out what data you are talking about, where it lives, who thinks they own it now, and what organization you need to address this effort. Here are some suggestions on how to make this go smoothly:
1. Identify External Data Ownership
  Often there will be multiple owners identified for the same data. Being able to identify these different uses in their various applications is a significant lever used throughout the rest of the process. Without a clear understanding of where the data is currently 'owned' and its criticality to various applications, mis-matched expectations will cause problems.
2. Formalize Ownership in MDM
  This often requires significant negotiation and compromise from the various stakeholders. In organizations where the inter-organization trust level is high, this is more straight-forward. In some environments, only a top-down directive will accomplish this. Whichever tactic is used, establishing formal ownership is a prerequisite for success.
3. Identify Data Domains
  This sounds a lot easier than it always ends of being. Attributes utilized by disparate systems often have subtleties in their definitions which must be accommodated. Being able to provide synonym mapping and transition approaches is imperative to keeping comfort levels high between organizations.
4. Formalize Domain Administration Process
  Having an established (and hopefully standardized!) set of processes to perform CRUD operations on domains can take the stress out of relationships where trust levels are sub par between applications.
5. Establish Organizational Governance
  This is often rolled up into Change Management or a similar phase, but in reality needs to be an ongoing activity. These organizational groupings will allow for escalation procedures, conflict resolution, and increased visibility into the data lifecycles.

Model Dimensions
If governance is properly addressed, this should be a fairly straightforward exercise for data architects. They'll go through some steps similar to the following:
1. Identify Dimensions
  What data are you really talking about? You need to pick a single name for each domain. Sometimes the same type of data is called different things in different places. You have to formalize on a common taxonomy.
2. Identify Consuming Applications
  There may be downstream consumers beyond the currently perceived data owners. Make sure you understand the data lifecycle and flows so you can estimate impacts properly.
3. Identify Entities Per Dimension
  Make sure you flesh out the taxonomy down to the most granular level necessary. The more detail you include now, the more hours saved later.
4. Identify Entity Attributes
  This is a critical step that is often treated as a second-class citizen. In reality, it is a key driver. Without precision about attributes, the potential values and rules (which come next) can't be properly defined. It also means your estimates will be incorrect.
5. Quantify Attribute Values
  This is only as important as the complexity of the data rules (which come next) and the accuracy of your rule implementation estimates need to be. If your sources have this well defined, it should be straightforward to ensure this is comprehensive.
6. Identify Data Rules
  This is sometimes referred to ambiguously as Business Rules which is very imprecise. Here we are speaking not to rules governing operations or activities (hence the term Business) but instead the states, lifecycles, and value cohorts for entities and domains.

As you can well imagine this is a significant undertaking for any organization, and can be done in a technology agnostic way. Once you've identified and quantified this information, you can begin to look at transition plans, data flow planning and infrastructure. These are very technology and environmentally specific.

As the proverb states: "Measure twice, cut once."

I Just Want My Media on My TV

noreply@blogger.com (Tempus Fugate) — Tue, 24 Jun 2008 00:12:00 +0000

The last couple of weeks have been ridiculously frustrating. All I want is to get my media, on my television, playing the sound through my stereo. This should be a no brainer, right?

Well it turns out that once again I must be just an outlying data point in the world of consumer electronics. What a frustrating adventure this is turning out to be. I've tried lots of different combinations with mixed bag of success and no clear winners. To start with here's a quick run-down of my basic requirements.

My media is on two big hard-drives:
- 1TB external hard-drives
- accessible via USB
- willing to share them over the net with an always on pc, but prefer to just plug them in
My media is very big and mixed:
- about 100K songs, from 10K artists, all in MP3, with cover art and ratings embedded in the tags (about 600 GBs)
- about 10k high-quality pictures (about 100GB)
- about 3K videos, mostly DIVX and XVID, organized in folders by type, series, season, etc. (about 400 GB)
I need to navigate music by playlists, artists, and genre. I've listed them in the order of importance to me. Playlists need to be 'smart' so they'll respect the ratings, genre, etc. that have been painstakingly maintained. For example, a playlist would be 'Songs in Genre = Folk, Subgenre = Acoustic, Rating > 3'
Displaying cover art from the file is a must. Displaying other tag attributes is a nice-to-have.
Displaying a picture slide-show while playing songs is a must.
- Being able to choose a specific directory is a nice-to-have.
- Being able to pick a set of specific directories is a nice-to-have.
- Assigning a set of directories to a playlist is a nice-to-have.
Being able to navigate videos by type, show, season is important.
Output via HDMI or DVI is important.
I have no interest in using a tv tuner, scheduling recordings or any of that other TV nonsense. So not having it in my way is a good thing.
Being able to edit ratings on screen is important.
Being able to create playlists on the fly is important.
Being able to shuffle by playlist, album, artist is important.
Media will get added routinely, so being able to monitor the folders on the drives is important.
Start-up time for spinning up music and videos is important.
Being able to navigate the very large amount of media quickly and by different attributes is important.
Being able to access this media from more than one television is important.
Being able to do all this without a dedicated, always-on pc, is only a nice-to-have.
Being able to get all this with commercial off-the-shelf stuff is important. I don’t crack boxes, and most soft-mods are off the table too.

When it comes to home electronics, I'm no slouch. I've been trying a whole host of devices and combinations. For example the Netgear EVA8000 Digital Entertainer HD and the Helios X5000 Network Media Player are two examples I've tried. They both really suck. Not only are they slow and can't do half of what I need, they are expensive and crashed often.

I do have a Windows Media Center pc (from Windows Vista Ultimate) which is a pretty good interface. And we have two Xbox 360's. There are multiple ways to connect these bad boys, but the really obvious one (as a Media Extender) doesn't seem to work out of the box. Being pretty good at figuring this crap out, if I can't get it to work after a couple long sessions of fiddling, it's just not meant to be (for me). Tips anyone?

One option I'm considering is the Apple TV. The interface is one of the slickest I've ever seen and the speed appears acceptable. But it won't play my videos without jumping through mod hoops and I'm not a fan of that. Unless someone has an alternative?

So now you know my predicament. What else should I try? Ideas? Anyone? Bueller? Bueller?

It's Been A Circus

noreply@blogger.com (Tempus Fugate) — Mon, 02 Jun 2008 23:43:00 +0000

Sorry for the delay guys!

Lately it has been a circus around here. Lots of new projects and learning going on these days. Who's in a recession? Not the tech industry!

So I've been working on Facebook Apps, MOSS customizations, writing tons of Silverlight widgets, reams of XAML and buckets of boatloads of WPF.

I'll bring you up to date on the latest shenanigans once things calm down a bit. Feel free to post questions if you want to spur my creative juices!

Leadership and Agile

noreply@blogger.com (Tempus Fugate) — Fri, 25 Apr 2008 18:23:00 +0000

This week I had several opportunities to speak with people about Agile.

As I listened to yet another discussion about Agile there were several things about the conversation that just really stuck out to me. It started with one strong idea of which I just couldn't seem to let go:

Agile is great under the umbrella of strong leadership. If the direction, metrics or criteria for success aren't well understood and broadly accepted across the organization, then returns on investment and efficiencies will likely not be realized.

In high-performing companies the gestalt is achieved when the employees are empowered to self-direction and a feeling of ownership. Even in these companies, that sense of empowerment and value is only powerful as the individual choices and decisions can be aligned to the bigger vision of the organization as a whole. When the vision or mandates of the organization aren't clearly articulated or fail to be fully accepted within the ranks, then organizations experience churn and confusion. Without alignment to a bigger mission, the agendas from the various levels of management tend to begin conflicting and drifting as individual interpretations of value and success criteria are formed. This churn due to conflicting expectations makes it easier for issues to hide and for misalignment to go unchecked for increasing periods of time.

Even in cases where misalignment is uncovered, the process needed to achieve consensus can then take longer and without strong leadership won't necessarily drive the business impact needed for growth or even sustainment.

This then is the crux. Leadership is essential for achieving business value. You can use Agile processes to seek business value, but without strong leadership you will find the criteria for success shifting too often and hiding behind the easy process of consensus building.

To bring this back to the Agile conversations, I was feeling frustration with the reactive nature of those who ascribe to the Agile approaches. They espouse this easy-going attitude of reaction in which direction, strategy, and even the definition of business value are left completely to the client. This zen-like state in which the Agile practitioner responds fluidly to the changing and ethereal nature of the client demands is unnatural and impractical. Business value is unlocked by making the hard choices, by understanding the elements of the business value and capability chain better than everyone else and leveraging that unfair advantage.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself.
Therefore, all progress depends on the unreasonable man.
-- George Bernard Shaw

Simply put, it is called work because it IS hard. It's painful and requires discipline. If you are choosing to avoid the hard choices you are inevitably giving up the business advantages, wasting opportunities, and releasing accountability. Live in a reactive mode long enough and you remove the incentive to estimate well, to live up to commitments, and to deliver beyond expectations.

As everyone in technology knows, regardless of how long a task should take, it always takes at least as long as the plan said it should. We don't finish early, we just fill up the extra time with more stuff and junk. We test a little more, refine a little more, increase scope if necessary. If you aren't pushing the boundary and requiring unreasonable attainment, then you'll never get it either.

When it comes to Agile, I embrace the incremental nature. I covet the consensus of reactive expectations. I do not respect the reduced commitment to discipline, the minimization of leadership, or the dismissal of accountability afforded a facilitator. As Harry would say, "If you are going to come, come correct." Harry can be very wise.

Free Code

noreply@blogger.com (Tempus Fugate) — Wed, 02 Apr 2008 00:01:00 +0000

Lately, I've been really paying attention to how much functionality you can reuse for free from major players. For example, you can check out the various Google APIs (http://code.google.com/)and the Yahoo! User Interface Library (http://developer.yahoo.com/yui/). These libraries are free, released via Open Source licenses, and offer ridiculous amounts of functionality.

As a developer, I love the idea of being able to leverage the work of other people. Most of the time, this is hard to do because so much of the code that everyone else writes is crap. ;-) But seriously, there is even a name for this, we call it Not Invented Here (NIH). The premise being most developers like to know exactly what their code is going to do, so using someone else's code can be hard.

In the case of the big boys like Yahoo! and Google, it becomes a lot easier to trust that the code is going to deliver expected results and not be malicious or buggy. After all, when it is provided (and used) by a company with billions of dollars of online reputation to uphold, you can pretty much bet they've tested it.

Which isn't to say that just because they are all that, you don't need your own bag of chips, they have their issues too. Dependency and version issues, occasional bugs, and warped programming models are abundant. But in the end, you are definitely getting your moneys worth.

The chart at the top of this post is generated using the super cool (and free!) Google Chart API which means I won't be paying for Dundas or ChartFX licenses again. You can find the details at http://code.google.com/apis/chart/.

Why Unit Test?

noreply@blogger.com (Tempus Fugate) — Mon, 10 Mar 2008 18:40:00 +0000

Recently, I had a down and dirty discussion with a team who is gearing up for a new engagement. This team has been doing Scrum for a while but was struggling with how to fold testing more tightly into their development processes.

The heart of the matter ended up being differences in the purpose and perception of Unit Tests specifically. One camp saw the role of Unit Test as "to find bugs". That's it. They tell you where the bugs are. If they are just about finding bugs, they have more value to new developers than established developers. After all, great developers are much less likely to allow the kind of bugs found by Unit Tests in their code. As a great developer I'm going to catch bad parameters and logic flaws before checking in my code. Integration and functional bugs are probably not going to be found in Unit Tests anyway.

The other camp (read: in my opinion) was resolute that Unit Tests fill a much larger purpose. To my eyes, Units Tests go way beyond just finding bugs. Following are four big ways that Unit Tests can add significant value over and above just finding bugs.

Proving Integration
Today's applications are more distributed and componentized than ever. The number of moving parts has just sky-rocketed with the use of frameworks and new API's, the prevalence of SOA and more component-oriented designs. Personally I see goodness here, but regardless if you like this direction or not, it's happening and is relevant to address. With this fragmentation comes a need to understand when the integration between components is complete. Simple Unit Tests can tell you quickly if the work being delegated downstream of a component is completed and ready. As you are bringing on multiple layers of components the pass rates of the Unit Tests at various layers can quickly show you the level of completeness for the entire integrated system.

Sample Code
One of the difficult parts of delivering a complete software product especially when the product is a framework or an API, if the product is extensible or supports programmability. In these cases specifically, Unit Tests can serve as great examples of how to utilize the API or exercise the programming model. They can often be directly consumed as documentation and sample code for SDKs or in knowledge transfers throughout the life of the product. Building this from outside the team without relying on the author of the component is extremely costly and difficult. However the returns are typically the most valuable.

Proving Design
Designing and building components is easy with the current toolsets. The downside of this is that we can create classes and objects so easily that we don't always think about the bigger picture. Taking time to write code that exercises a new component or interface can act as a sanity check to ensure that the component is easy to use and meets the programmability desires. It's quite often that I see a single API that requires two or three different programming or data interaction models. Some quick Unit Tests would have shown the designer how difficult and inconsistent the usage of the API had become.

Change Management
As a great engineer, it might be totally natural for you to write code that has few bugs. Are the engineers who take up your legacy as experienced? Will the engineer who will open the code in six months to add some features or fix an integration issue be as comfortable knowing how to change things without breaking anything? Would you? Being able to run regressions over time adds a wonderful safety net in the identification of the impact of changes upstream, downstream, or inside your code. It doesn't mean you will (or can) catch everything with Unit Tests but it can sure give you a head start and a level of confidence.

So perhaps this is more about semantics or expectation setting, but I think it helps to keep in mind the variety of purposes Unit Testing can serve. When you expand the contributions made by Unit Tests hopefully you will have an incentive to get even your experienced engineers to spend time writing them.

Are You Sure?

noreply@blogger.com (Tempus Fugate) — Wed, 05 Mar 2008 05:07:00 +0000

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.

Offshoring for Rank and File

noreply@blogger.com (Tempus Fugate) — Wed, 20 Feb 2008 17:16:00 +0000

I've been doing offshore work as long as the next guy, if the next guy has been doing it for almost a decade. There are successes and failures and lots of learning along the way. It's hardly the only thing I've done, but it's a good share of the pot.

Recently, I was asked to speak with some gents about how their offshore effort was going. Which is usually code for "We don't think it's going well". And by all accounts from the team, it wasn't going all that well. It helps when everyone at least starts from the level of dissatisfaction.

Whenever we start to talk about the concept of managing work efforts in more than one location, everyone spits out the same mantras. Communicate, be sensitive to cultural differences, etc. The thing is there aren't all that many that have moved past the theory into practical application. I should say demonstrably successful application. A big part of this shortcoming, from my perspective, has been that while we can have concepts in our heads like cultural differences, and detailed communication plans, we miss what can be the subtle point of these guidelines.

Let's borrow from a recent experience at Big Redmond Software Company. Companies (like Microsoft or Google) don't really run tight ships. Not in the way the unfamiliar would think. At the foundation, they expect individuals to be very self-sufficient and to work with minimal communication. Contributors are expected to bridge gaps in their own style. These companies are impactful because they have leveraged the ability to walk down the hall and say "Build this" while pointing to the contents of a Visio diagram or the corner of a whiteboard. The resources are expected to be accountable for the applicability and context of their solutions, not just the code or outputs they produce. The business value driving the work should naturally be taken into account by the self-reliant resources who are tasked with unlocking that capability.

When you start moving that work to different geographies and timezones, suddenly that level of communication isn't enough. The expectation on all parties is to minimize communication since that is a cost both parties share. But how they each tend to approach that goal is often different. Remember that the sender is expecting to point and grunt and have accountability and context magically shift. They'll be available for questions, they expect to review the progress and deliverables and throw stones along the way. But if it takes more than [insert arbitrary threshold here] energy and time commitment, then it just isn't working out. It would have been easier to do it myself in house.

Meanwhile, the receiver of the work has an expectation that the work will be fully-formed, coherent, and that they will not have significant decision-making requirements. Give me enough information up-front to be self-sufficient and yardstick with which to measure success. I'll come back when the output meets the success criteria. My accountability only extends to the output according to the specifications and acceptance criteria. If those have been ill-defined, that is the senders responsibility.

Obviously, I over simplify a little and as always YMMV. But in practice, understanding the different accountability and communication expectations we place on resources on different sides of a pond (or client-facing fence) will help you be more successful at leveraging offshore resources.

How "Open" Can It Be?

noreply@blogger.com (Tempus Fugate) — Sat, 02 Feb 2008 19:57:00 +0000

Something that has bothered me from the beginning of the Open Source movement (and I use the word very loosely) is the seeming hypocrisy of these commercial companies that have huge revenue streams based around the idea of Open Source software.

Not to go off on a rant here, but how open can they really be when they've got hundreds of people paying money for them to support their specific releases? To my mind the idea of Open Source was always that the source could and would be extended by the community at large. However if you are going to start asking people to pay for the specific versions of extensions that you are providing, you've essentially closed the system. At this point, it seems to me you aren't an Open Source contributor any more. You are someone who took an Open Source offering, tweaked it, and are now asking people to pay for your tweaks, thereby closing it. If you did this once, perhaps a point could be argued, but when you've been building on YOUR specific tweaks for release after release, and your support policies are version specific, then you are just like any other software company. Okay, perhaps there is a little more transparency into the code, but still.

” SANTA CLARA, CA January 16, 2008 Sun Microsystems, Inc. (NASDAQ: JAVA) today announced it has entered into a definitive agreement to acquire MySQL AB, an open source icon and developer of one of the world's fastest growing open source databases for approximately $1 billion in total consideration. The acquisition accelerates Sun's position in enterprise IT to now include the $15 billion database market. Today's announcement reaffirms Sun's position as the leading provider of platforms for the Web economy and its role as the largest commercial open source contributor.”
From: http://www.sun.com/aboutsun/pr/2008-01/sunflash.20080116.1.xml

Exactly how open to the inputs of Joe developer are they really going to be when they have to sustain a $15 billion dollar Support industry around these products. Do they really expect us to believe they are going to leave the evolution of these products to the average engineer? The community at large? Hell no. They have product teams and planners and release strategists just like every one else. They just don't have the huge upfront investment in research and development, they essentially jumpstarted their code from the masses. And they won't have a huge testing effort, they'll just rest on the backs of the industry at large. Which makes for good stability.

I hate to see such blatant parasitical behavior cowering behind the beauty that could be Open Source. Greedy bastards.

Running The Gauntlet

noreply@blogger.com (Tempus Fugate) — Thu, 17 Jan 2008 01:15:00 +0000

This week I had the chance to discuss using Team Foundation Server in a large team setting specifically as concerns Build and Deployment.

As I was organizing my thoughts to answer a question about check-in policies, merging and branching, and so forth and I kept coming back to my guiding principles:

The Build is the build. There is only one Build.

Build anywhere you like, as much as you like, but it only counts if it is in the Build.

If it doesn't work in the Build, it doesn't work.

Now I am certainly familiar with having to manage simultaneous release schedules, juggling branches, and so forth, but that doesn't mean I like it. I absolutely support the mainline concept. Much like the Highlander, when it comes to the build, there can be only one.

We could argue that there are many techniques to allow these fancy behaviors but that doesn't make it okay. Just because you can do something, doesn't mean you should. Experience tells us that if you have a big team, you can't afford to have anyone interrupt the flow of the system. This includes breaking the build, causing failures of critical tests, etc. When more people or organizations are involved, the cost increases.

In the agile communities there is a push towards Continuous Integration (CI) which is really an attempt to implement the Only One Build concept as an ideal. When you can do it, you should. When the amount of code grows or the number of loose connections increases this can be cost-prohibitive, primarily in time. Compiling 1.8 million lines of code is going to take a little while regardless of how big the build machine might be. And when it comes to running Build Verification Tests, these problems are compounded. Especially if you are using disparate services that are loosely coupled.

The idea behind CI is to bring compilation and integration issues to the attention of the team as soon as possible thereby minimizing distribution. Going beyond that are tools that would actually test code entering the system before check-ins occur and reject or accept them based on the results. With TFS policies this is fairly straightforward to set up and an open source effort has begun to bring this to life. You can find out more about this effort at http://www.opengauntlet.org/.

If you prefer to wait until this functionality is built-in, you'll be glad to know that the next product release most likely will include a similar feature with a working title of "Gated Checkin".

I Need A New Phone

noreply@blogger.com (Tempus Fugate) — Mon, 24 Dec 2007 01:38:00 +0000

My friend has a cool Nokia with a 3 or 4 megapixel camera and it just puts my Dash to shame. Which means that now I'm in the market for a new phone.

Here are some things I care about in weighted order of importance:

1. 3+ megapixels
2. autofocus
3. windows mobile 5+
4. works on t-mobile
72. standard headphone jack
74. sd card slot
81. flash
89. gps

So any ideas?

Right now I am considering the HTC Touch Cruise and the HTC TyTN II. But I'd love to find some more options to choose from. Surely there are other choices?

Outlook 2007 on Vista accessing Exchange using HTTP over RPC

noreply@blogger.com (Tempus Fugate) — Thu, 06 Dec 2007 17:41:00 +0000

If that title didn't mean anything to you, ignore this post. (Well, you can click an advert on the right first! ;-)

Just recently I've updated my laptop to the latest Windows operating system release named Vista. Since I'm out in the field, I don't have a nice persistent connection to my corporate network and Exchange mailbox. After installing Office 2007 (which I'd been using for some time and can say is quite good!) I needed to get my email configured again. So I point and clicked everything as it was configured before. Alas, no joy.

After researching a bit online including a very poorly worded and far too succinct KB article (found here), I got it running again. I've listed the important steps below, skip them at your peril.

Open regedit or your other favorite registry editing tool.
If this is unfamiliar go get your geeky computer friend to help. You can really screw things up playing in the registry, so only do this if you know what you are about.
Locate the following subkey:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC
You might not have the RPC portion of the key. I didn't. Just create it if missing.
Add a new DWORD value named DefConnectOpts with a value of 0.
You have to get the name correct, and make sure the value is set to zero.
Restart your machine.
This is usually the first step I skip. You can't do it this time. It won't take effect until restart. There probably is a service or .dll that can just be unloaded, but what a hassle. Keep it simple and just reboot.
Delete the profile you had, and recreate it with valid settings.
At this point it should let you login to your Exchange server via RPC over HTTP. If it didn't you probably skipped a step or hit that special "you're screwed" portion of code. Call your techie friend.

My default Vista install did not have the RPC portion of the above key. So, I just created the key, then added the new value. I first deleted the old profile, then rebooted the computer. I created a new profile and it worked. Your mileage may vary.

3 Pass Coding

noreply@blogger.com (Tempus Fugate) — Sat, 24 Nov 2007 18:46:00 +0000

Back in the day at Microsoft we used to look for and train developers who were 1 pass coders. In today's world everyone is a 3 pass coder and they are starting to drag me down with them.

Let me explain the difference between a 1 pass and a 3 pass coder.

When you are writing code there are several layers (or aspects) of design and implementation activity that have to be balanced. Firstly, you have the very simple, but often disputed, question of whether the code will meet a functional objective. This is often referred to Working. If the code won't perform the purpose the code is intended for it Doesn't Work and the rest of its qualities aren't relevant. Assuming that it can be made to fulfill its intended purpose (i.e. it Works), then the other two aspects suddenly become important.

The next most tangible aspect of coding is the speed at which the code will execute or process units of work, transactions, operations, etc. Regardless of the velocity or metrics implied, the measure of this aspect of coding is generally called Performance. Making something Work is the first step which is immediately followed by does it Work Fast.

Lastly you have a host of intangibles of varying degrees of importance. There can be many tangible expressions of these intangible attributes used by different people at different times. The number of comments, the readability of the control flow, the robustness of the error and state management, and the lack of logic or bounding bugs; are all examples and all of which are related. We put these closely-coupled items in a big bucket called Quality. This may also referred to as Maintainability, Elegance, etc. If you can make it Work, and make it Work Fast, can you make it Work Correctly?

Now when someone starts out coding, they generally are capable of keeping only one layer in their mind at a time. They start by making the code Work. They just want to see it do what they think it should do. Of course, once it does that, then they immediately concern themselves with making it Work Fast. It is about this time that consumers of their code start exercising the possibilities and uncovering flaws and boundaries of the code. So a review of code usually focused on specific bugs or concerns is undertaken until eventually it is determined the code must Work Correctly. This lifecycle usually involves 3 distinct reviews or Passes on the code. It is written, then reviewed for performance or capacity, then again for bugs and boundaries.

On the other hand, a 1 Pass coder will have such a clear picture in mind of the code, the control of flow, the logic loops, the impediments and enhancements to speed, the boundary conditions and bug potentials, that the exercise is compressed into a single Pass of coding. All the work is done upfront in the design and in the construction of each line so that intangibles are caught during the initial pass.

At least that's how we used to do it. It's how I used to do it.

Now engineers are so woefully under-skilled. They aren't forced to learn logic or bit math. They didn't take any classes on algorithm design or perform exercises on bug potentials. They just want to see it Work and then have testers tell them what else needs fixing. If you want it to Work Fast they just buy bigger boxes or more of them. The days of discipline are gone.

When I have to oversee their work or explain an implementation I find myself being forced to speak in terms of what it takes to make it Work because the other layers trip them up. If I show them tight, elegant code with robust error and state management and efficient control of flow, they can't read or follow it. When I assign bugs they want to debug and watch the code execute because they can't find the bugs by reading the code. I have to worry about losing my own skills just working alongside them.

Yesterday for a personal coding project I came across a bug running the program and my first thought was to set a breakpoint and see what happened. I wanted to slap myself out of the chair! I'm better than that. I can READ and understand code. Which doesn't mean I don't take advantage of the debugger, but it shouldn't be my first thought. I'm a 1 Pass coder and I intend to stay that way.

Eventual Correctness

noreply@blogger.com (Tempus Fugate) — Tue, 23 Oct 2007 15:41:00 +0000

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

noreply@blogger.com (Tempus Fugate) — Fri, 19 Oct 2007 23:23:00 +0000

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.