Neo Diem

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.

Dead Man Walking

noreply@blogger.com (Tempus Fugate) — Wed, 17 Oct 2007 16:18:00 +0000

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!

noreply@blogger.com (Tempus Fugate) — Tue, 16 Oct 2007 17:37:00 +0000

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.

Don't Get Bullied

noreply@blogger.com (Tempus Fugate) — Wed, 12 Sep 2007 15:59:00 +0000

Building software for a crowd of generic consumers while challenging, operates by some reasonably straightforward rules that can be reasonably understood. For example, simpler is better.

On the other hand, building custom software for an educated user-base to fulfill specialized processing is excruciating because of the unreasonableness of it all.

The closer your users are to the problem, the more ideas they will have on HOW to solve the problem. This naturally leads to a slew of fragmented and disjointed concepts as they attempt to articulate in fits and starts their individual, informed, ideas about how the system should function.

At the other end of the spectrum, having educated and empowered users who will discourse with you about the nature of the problems to be solved, listening with open-minds to potential solutions, providing feedback to perfect the product, this can be hyper-productive.

We like to say, "They know enough to be dangerous."

When you have fragmented and disjoint components that don't subscribe to a cohesive approach to problem resolution you end up with lots of superfluous code that is usually much more complicated then it needs to be. Twice as much code doesn't make the solution twice as complex, more code adds exponential complexity.

This is not to say that you altering the end-goal for the functionality being delivered, you are changing HOW the software will meet the end-goal of functionality. When you subscribe to a cohesive vision, the product isn't just easier to create, it is simpler to test, quicker to validate, more robust in operation, faster to debug, and much easier for a user to adopt. The evidence supporting this is vast and varied across the technology landscape. The simpler answers always have broader adoption.

When you approaching an engagement, ask yourself what kind of user-base is supporting your efforts. Are they generic and uninformed? Keep it simple. Are they educated, pushy, and sure of their solution? Good luck with that (unless you can change the game). Are they empowered but open? Engage them early and often and you'll be really successful.

Is That Your Hand In My Pocket?

noreply@blogger.com (Tempus Fugate) — Fri, 07 Sep 2007 15:47:00 +0000

Yesterday we heard from our own news sources about a recent release from the US Justice Department about allowing fees for priority routing of internet traffic. Today, courtesy of the BBC, we see a simple restatement.

The US Justice Department has said that internet service providers should be allowed to charge for priority traffic.

The agency said it was opposed to "network neutrality", the idea that all data on the net is treated equally.
-- BBC News

Why can't our news ever spell anything out this simply?

What’s next? An Uber-Elite Network that’s much faster than the current one…oh wait, we already have I2…
Well how about a private network that you have to pay for higher bandwidth…oh wait, all the major carriers already do that…

Hmm…something is fishy about this, I just can’t quite put my finger on it.

Come On, Jump On

noreply@blogger.com (Tempus Fugate) — Thu, 06 Sep 2007 18:20:00 +0000

Big projects are great.

Okay, I work in consulting so that seems a little obvious. But hear me out. Big projects aren't just excellent because they usually mean big money. They are also great because of all the intangible benefits and unaccounted for side-effects.

When people are working on big projects, the little inefficiencies and mistakes they are used to compensating for become exaggerated and glaringly obvious. Likewise, those who can really deliver get an opportunity to do so on scale that is unmistakable. Your performance or lack of it is much easier to identify when the magnifying glass that is a large project is applied to it.

Of course, it isn't just personal performance. The demands of your clients, the companies you work with, the policies you have in place for growing people. All these are put under the stress of longer durations, more bodies, and a much wider diversity of insanity.

The meta-lesson for me here is; if you, like me, have the tenacity to jump onto the back of a moving band-wagon then it seems polite to let the guys at the front do the driving.
-- David Ing (From 9 till 2)

One cool thing I really have come to really appreciate is how the gravity well of a big project showcases the motivations, self-sufficiencies, and sometimes even the loyalties of those you work with regularly.

Let's face it, steering a titanic is hard. Really frickin' hard. If it is for only a short time, or when the penalties are small, you can overlook lots of sniping, counter-productive, or selfish behavior. Start stretching the durations or increasing the costs of failure, and watch how the spotlight finds those who act counter to the culture or the company.

The Traits You Can't Fake

noreply@blogger.com (Tempus Fugate) — Fri, 17 Aug 2007 22:14:00 +0000

From project to project and company to company, the question about how to find great resources, how to interview well and weed the gems from the rough has consistently arisen. This problem is closely related to the situation faced when trying to figure out who to reward and how to measure contributions for individuals in vastly different roles or environments.

Whether evaluating a candidate for a potential fit or comparing two very different but competent engineers, I have found there are two traits that help me separate the wheat and the chaff.

I prefer the folly of enthusiasm to the indifference of wisdom.
-- Anatole France

First off, you can't fake enthusiasm. There is simply no substitute for the intangible value that enthusiasm supplies. Someone who is consistently happy and has only average ability is worth far more than someone who is very skilled but always grumpy or disgruntled.

If you are not fired with enthusiasm, you will be fired with enthusiasm.
-- Vince Lombardi

Ask yourself if you trust that they'll get things done if (and when) you leave them alone. Find out if they're looking to get on your specific bus, or if they are just looking for a ride, any ride. Make sure they can demonstrate passion for both positive and negative things around them. Even the most staid among us can get passionate about things we love or enjoy. But if they are broadly accepting of all annoyances, they probably aren't going to be very creative about working efficiently. If they won't talk about the little things that bother and motivate them, they probably lack that insistence on quality that true performers must have. Likewise, they should be able to articulate why the things they enjoy are enjoyable! If you can't get pin them on both extremes, rest assured their work product won't be either.

Creativity is a natural extension of our enthusiasm.
-- Earl Nightingale

The second trait is a follow on to the beauty of passion: inquisitiveness. Given opportunity, do they ask lots of questions? People with passion want to understand problems and propose improvements. The natural state of an evolving mind is to be filled with questions. Smart people, experienced people, know that questions are an imperative prerequisite to understanding. If they don't want to ask questions, they aren't really seeking to understand.

Curiosity is, in great and generous minds, the first passion and the last.
-- Samuel Johnson

When you observe how someone questions, you see how their mind works. You see the speed with which they assimilate and incorporate new information. You often will see the clues to their biases in the solutions they espouse; you can see how disciplined they are by how they stay on focus or by how rigorously they apply new vocabulary. When questions don't have answers or answers that are incomplete, you can glimpse how they handle frustration, disappointment, and even their own ignorance. One of the quickest and surest ways to gather insight into the mind of another is to watch them learn something new.

Curiosity is idle only to those who fail to realize that it may be a very rare and indispensable thing.
-- James Harvey Robinson