Mike Schubert

I was driving along the other day and my "Check Engine" light came on. This is an ominous occurrence because this light can be an indicator of a looming system failure within an automobile. The catalytic converter could be on its last legs (you won't pass the emissions inspection), there could be an engine seal broken that is causing a loss of compression (or allowing something into the block), or any number of other things. In short - this light is worthless. It means you need to take it to a mechanic to read a code.

Why they couldn't just add a little LED display onto the dash panel to help me out, I have no idea. Maybe there are a bunch of System.out statements that would generate so much noise you'd be confused. This is exactly what happens in software development. As people debug problems in their code, they implement statements to help them track the flow (this is especially true for web apps when you can't monitor server processes). With a little bit of care, these messages can implemented as part of a framework - Log4net, for example. If you think through "what can go wrong in this section" and "what would I like to know to diagnose it" or "what conditions indicate something bad is going to happen" you can more thoughtfully instrument your code. Adding monitors on top of this implementation to alert on particular messages or conditions then becomes a trivial task. Unfortunately, all too often useless messages get generated in a non-managed way and the signal to noise ratio become unbearably small. 

As for my "check engine" light? Apparently on a cold morning when I filled up my gas tank, I didn't turn the gas cap until it clicked 3 times. There was nothing wrong with my engine. Here's how I imagine that poorly written code block looks:

try{

   MonitorFuelSystem()

}catch(GasCapException e){

    System.out.println("Ignore this exception");

}

Thanks for turning the light on and freaking me out over nothing.

3d person and globe
Originally uploaded by 姒儿喵喵

Over the last decade, many lessons have been learned about sending software development work overseas. These lessons have been documented in books, magazines and blogs the world over. Many lessons are similar to those that you would face if you chose a consultancy down the street from you. Others are simply lessons of doing business with cultures foreign to your own.

For those who have been working with offshore partners for a number of years, what I write here on the subject will be a "no duh" moment. Others looking to embark on a pilot of sending work overseas may think "this won't happen to me." Regardless - what I write over the coming weeks and years will be my observations and a sort of record of my experiences.

My thought for today is this -> It can be more challenging than it might appear. On the surface, the idea sounds great. You do the customer interactions, the requirements definition and design work - then turn it over to your partners to implement. But what if there are issues? When the work is done within 3 timezones of yourself, getting people together to discuss the issue is very straightforward. Even emailing back and forth is possible when the timezones are close.

But the problem with sending work 12 timezones away is the lag in time. If there is an issue that impacts delivery dates, resolving it via email is a guaranteed way to miss your deadline. One model that has worked well is to use an "onshore coordinator" - a technical individual that works for your offshore partner whose job is to interface with you and the offshore team and work across time boundaries to get issues resolved. 

One final thought on this matter is this -> no matter which of the above options you take, whether you have an onshore coordinator or you are up at midnight on the phone - YOU are the bottleneck. It may be that the team overseas is incompetent, but it's your job to make them competent (or take some other action). If systems are unreachable, requirements are unclear, or deliverables are of poor quality it is your responsibility to remove the obstacles and rectify the situation. If you execute well, your chances for a successful program are higher.

transparent screen
Originally uploaded by fromform

Part of my job involves evaluating and recommending IT solutions to business problems we face. I have a wide background in technology and do not fit the mold of a "Java guy" or "Microsoft guy". This can be exasperating for some as they try to figure out which direction I lean and offer me sales spiels to convince me toward their product.

Even more troubling to sales reps is determining how I view solutions from IBM, Microsoft, Sun and Cisco. My previous employer was a business partner / gold reseller for those vendors and you would think that I automatically drank the kool-aid. There are people that I work with that have obvious biases towards some vendors due to past affiliations and/or friendships. If it works out for them, great. But that's not how I roll and I do not appreciate people toeing a company line for a company they don't work for.

I will always prefer the solution that supports the most features my business partners require, with the lowest initial and recurring costs, that has the best chance at adoption and longevity within our environment. I don't fit any mold - I make the mold.

Once a week I receive an email from Monster.com with a snapshot of the career opportunities available in the Atlanta market. This morning I clicked thru one of the postings for an IT Manager at Emory University. Emory is a well respected, private university located just outside of the city. In these job descriptions, it is not uncommon to list percentages for categories so you understand the makeup of your responsibilities. For this position, the following breakdown was offered:

So your job responsibilities set a written expectation for you to give 120-130%. I wonder how many people will apply.

The social software of the Internet has been a real curiosity for me over the past 3 years. People are essentially putting their entire social life on display without giving it a second thought. Things that were once kept amongst a close knit group of friends are now being shared with total strangers without a second thought.

Looking at this a step further, relationships are being built in cyberspace in ways that would NEVER take place in the real world. Could you imagine having a conversation with someone 140 characters at a time in real life? And what exactly does the "Poke" button on Facebook do? Here is a quick video showing you what real life would be like if it actually mimicked Facebook. Enjoy!