Turtles all the way down

You don’t catch partners with the partnership trap. The partnership trap is not a physical entity. It is a belief, borne on the wings of hopeful optimism, that you can partner with another technology / software company to deliver products that better address markets, satisfy customer needs, and will ultimately make both companies more successful. Partnership is usually more than meets the eye, and in the worst cases, a major loss of time and money for both companies. However, partnerships can work.

The common denominator of successful partnerships that I have observed is the degree of coupling that is required or rather, the lack thereof.

Suppose that two software companies, Distributed Object Graphics (DOG) and Coordinated Active Technologies (CAT) each produce products that perform certain niche functions. Both are well into the sales cycle with a very large and lucrative account when they become aware of each other. The customer turns out to want a combination of their two products, and has decided that each standalone product will not be sufficient. In fact the customer may make the introduction between DOG and CAT and ask them to work together.

The executives of DOG and CAT are initially pleased and sign an appropriate MOU, LOI, NDA, or some such similar three-letter agreement to work together and respect the other’s intellectual property. As the two companies move forward, this story can play out in several different ways.

• DOG and CAT can make their two products work together by using a common, standard interface between their offerings. Development and internal test of this interface ensues, then they move to lab interoperability test. A few bugs are fixed and then a solution is brought to the customer.
• DOG and CAT need to figure out how to get both of their offerings to work as two separate applications on the same hardware platform. This takes more time and energy from both companies, as the behavior of one application can impact the behavior of the other in subtle ways (e.g., memory usage, CPU usage). The number of test cases scales multiplicatively with the test cases associated with each individual product. After a long testing cycle, the integrated product is ready, but questions remain about its stability in certain scenarios.
• DOG and CAT have to integrate at the code level. Engineers from both companies need to work closely together for long periods of time determining the most efficient and effective approach. Each company is reluctant to expose too much of the proprietary software to the other. The investment that needs to be made in this sort of solution is so great that each company is reluctant to continue dedicating their resources to the project, even though the project sorely need active management. Each company tries to get the other to do the more time consuming and expensive tasks of integration. Disagreements are frequent and tempers flare. The result (if the project in fact completes) is a solution that no one is happy with, including the customer.

Partnerships are not a magic pill that solves all problems - they result in a new product offering that needs its share of development, testing, and management. Additional resources are required. Many organizations will not realize this and will walk into partnerships that look great on paper but do not deliver because it is assumed that the resulting product comes for free.

Who you partner with matters. Make sure your partner is technically competent and has a good track record, or at least a solid reputation in the industry. Where your partner is in the world matters as well. If your partner is headquartered 10-14 time zones away from you, as is the case between North American and Asia, communication will be difficult and travel will be long and expensive. Language and cultural barriers will also threaten your partnership, so be aware of them and budget for the appropriate training and overhead. And be wary of your partner’s motives. Large companies sometimes find smaller partners to fill a gap in their product offering for just long enough to either find another partner or develop the product themselves.

The more tightly coupled the combined product offering is, the more likely that new features will lag each company’s standalone versions of the product. Additionally, defects will be harder to find and debug. If the combined product is deployed, the customer will quickly become frustrated if the two partners spend more time finger-pointing than working to resolve the issue.

To repeat the general rule, the greater the degree of integration, the tougher and longer the project will be. Don’t be fooled by statements such as “We have A and they have B, so if we combine what we have, we get A+B.” In reality you often get something less than A+B at an additional cost. In order to minimize risk in any partnership, know your partner and their motivation, make the requirements on each party very clear, and be ready to dedicate the appropriate level of resources to make the partnership successful.

The perfect employee is smarter than you are but doesn’t want your job.

The perfect employee can do his or her job better than you can.

The perfect employee does exactly what they are told unless they have a better way of doing what you’ve asked for, and then they will consult you first before doing it their way.

The perfect employee does not whine or complain.

The perfect employee makes you look good, especially to your peers and superiors.

The perfect employee can be trusted with any task that you need to delegate.

The perfect employee knows exactly what you need when you give a vague request or directive.

The perfect employee gives you early warning of potential risks.

The perfect employee gives you an honest and prompt readout when there is bad news.

The perfect employee promptly follows up on all requests.

The perfect employee requires little maintenance and face time.

The perfect employee is cordial and agreeable when asked to work outside of normal business hours or overtime.

The perfect employee does not exist, but if you are lucky you’ll work with a few people who come close.

In a software company, a science project is an undertaking done outside of normal procedures. You throw a couple of crack engineers at a hard problem and see what they come up with. Not that all science projects your company might do are bad, but some may cross over to the dark side. You can tell that a science project has joined Darth Vader and his Sith brethren when a conversation like this one happens (Carl is the boss):

Alice: “It will take us 10 weeks to add that feature to the product.”

Bob: “You’ve got to be kidding me! I had one of my guys bang that feature out in two weeks!”

Alice: “Sure, but you didn’t follow our development process. You code won’t integrate cleanly, nor does it make use of the libraries we’ve already developed. It was written without a design specification and there was code inspection or no unit testing. I’m sure it will work for a few sunny-day scenarios, but will it handle all of the known error scenarios properly?”

Bob: “Of course it will! My guys are really good and all of that process is just slowing us down. We already have the code written so why duplicate effort? Let’s just integrate what I’ve got.”

Carl: “Alice, we cannot afford to have our engineers doing redundant work. Go ahead and integrate Bob’s code. It will get us to market faster. QA will find any bugs. You should be grateful Bob was kind enough to help you out.”

Alice: “But…”

So Alice grudgingly integrates Bob’s code, finding that she has to have her team re-write half of it to build cleanly. Bob’s engineers are off on another science project and “don’t have time” to help Alice’s team with the integration. Two weeks go by.

Unit tests have to be developed, written and executed against Bob’s code. Bugs are found in Bob’s code and since Alice’s team is not as familiar with the code (not to mention that it was poorly documented) it takes longer than expected to resolve the bugs. In the process, more re-writing is done. Four more weeks go by.

This first drop to QA occurs and fails miserably. The QA manager complains to Alice that the code is a brick. 70% of the bugs in the overall product are found to be in Bob’s code. Entire sub-features are missing from the code, and sunny-day scenarios only work half of the time. A good portion of the test plan for the new feature is blocked. Alice has her team work evenings and weekends to fix the problems. Two more weeks go by.

The second drop to QA looks much better but the poor quality of the first drop has put the project two weeks behind schedule. Alice coaxes her top people to continue working longer hours. At this point only 10% of Bob’s original code is still in the product - Alice’s team has refactored 90% of it. Two more weeks go by.

The third drop to QA passes most test and is of acceptable quality, so the product is given a green light to ship, two weeks late.

After the product has been with customers for a month, it fails mysteriously. Alice’s team burns more midnight oil anaylzing logs. Bob’s team refuses to help because their “code was modified” and eventually a race condition and a couple of memory leaks are found. The product is patched and sent back to the customer.

Three days later the product fails again in a different fashion. More long hours from Alice’s team and a coding error in a single line of code is found that very likely caused the problem. This time QA is brought in to run a full regression cycle on the second patch. After the tests complete successfully the code is sent back to the customer. However, the customer is very upset at this point and invokes a “10% refund penalty clause” of their contract with Alice, Bob and Carl’s company. A six-figure credit is given to the customer.

Alice resigns in disgust, forms her own software company, hires her old team and they go on to be very successful. Bob gets Alice’s job, fails to ever ship a stable product on time but gets promoted to Vice President because his aggressive schedules always make sales and marketing happy. Eventually, Bob’s company loses market share to the competition, struggles for a few years, then shuts their doors.

The moral of the story? Science projects can be wonderful. But they are not products. They are science projects. Be very careful to do the proper diligence when productizing a science project, and they are usually not designed with productization in mind. Be prepared to redo the project from scratch if necessary.

I consider myself an amateur transportation engineer.

I commute 30 miles each way, to work and back. On a good day I can make it door to door in less than 35 minutes. On a bad day…well, 90 minutes is not uncommon. Throw in a sudden snow storm and I’m looking at 3 hours or more. I’ve been doing essentially the same commute for 10 years and have spent my fair share of time sitting in a virtual parking lot thinking about how to not be sitting in a virtual parking lot. Most of my customers over this period of time have been telecommunications operators, and I can’t help but think that their expertise could be applied to relive highway congestion…

Some of the principles of network engineering that I’d like to apply to highways include:

• Design for the busy hour. On the average, most roads are not congested. During rush hour, most of them are congested. Design roads to support the traffic patterns at peak load.
• Observe a maintenance window. Don’t do road repairs from 7am to 3pm. Do them between 8pm and 5am. Closing a lane during rush hour impacts a tremendous number of individuals, has a ripple effect to other roads and highways, and extends the duration of rush hour. Closing a lane at 1am minimizes this impact.
• Eliminate bottlenecks. A great deal of congestion seems to be resulting from a small number of bottlenecks, such as a poorly designed merge or a major intersection. Add extra lanes before during and after large intersections.
• Utilize redundancy and load balancing. For an major artery, make sure there are viable alternate routes in case of accidents or congestion.
• Discounts for off-peak usage. Make tolls effective only during rush hour in order to motivate drivers to drive at other times.

Ok, ok, implementing these principles will cost money, probably a lot of it. I have two arguments addressing the issue of cost.

The first is that doing nothing and leaving the roads and highways the way they are now has a hidden cost of reduced productivity. The more time we spend sitting in traffic the less we have to work or to spend with family. Stress levels increase, and tempers flare, potentially igniting dangerous road rage incidents. Not to mention that more idling engines create more pollution, speeds global warming, etc. (insert disaster scenario here). So the dollar cost of road improvements need to be weighed against these factors. Sitting in a traffic jam is a giant, unproductive waste of time and money not just for me but for thousands of my fellow commuters as well.

The second is to address the congestion issue by reducing demand. Provide reasonable alternatives, such as cheap, safe and efficient mass transportation. The cost of providing improved mass transit should be weighed per the discussion above. Additionally, if more companies offered their employees options such as flex time and the ability to work from home one or more times a week, traffic would be reduced and the rush hour peak would be smoothed out. Given the high price of gas, employees would be happy as well.

My 2007 Honda Accord is the first car I’ve ever owned that has a good cupholder design. My previous vehicles, including several Hondas, either didn’t have cupholders or featured ones that would cause cups to rattle incessantly or spill drinks if you took a turn too fast or hit a few bumps.

This year’s Accord lets you slide your cup into a holder that gently grips it. No spills or rattles so far. I’ve tried it with coffee cups (Starbucks of course), plastic water bottles and glass iced tea bottles. Too bad Honda took so long to get it right, but kudos to their designers anyway.

I recently stepped down from my adjunct faculty position at Northwestern’s excellent Masters of Information Technology Program. I was asked to write a letter describing the decision.

The linked article also contains an awful picture of me, proving once again that I’m one of the least photogenic people on the planet.

I’ve been on something of a health kick for about 10 years now, which probably makes it more than just a kick. I’ve been lifting weights regularly or semi regularly for about 15 years. I’ve learned a few things over this time and, though I don’t claim to know that much or to have any special expertise, sharing some of this information might help others.

My work, travel and family schedules determine when and how I work out. Currently my heavy workouts happen on Saturdays and Sunday, and lighter workouts on select weekday mornings. This is not an ideal schedule as I’d prefer to hit the gym more frequently, but it works for me.

The weekends are for strength training while weekdays are for cardio. I’ve divided, then mixed and matched muscle groups, to hit every major muscle area at least once a week. I used to work out using the same routine two or three times a week, but I’ve noticed a difference when I moved to a muscle group oriented approach.

My basic strategy can be summarized as:

• Build strength and mass: Lift very heavy weights with 5-8 reps per set, where the last rep is extremely difficult.
• Hit the same muscle from different angles: For example, exercising the upper pectorals with a series of bench presses, incline presses, flys and cable cross sets.
• Mix free weights and machines: Free weights are great for improving balance and getting a total workout that includes lesser-used muscles, but machines are necessary for heavy lifts since I don’t use a spotter.
• Don’t let the routine get too routine: Mix it up. I change the order of my routine regularly: do it in reverse, experiment with new lifts and techniques. I don’t want to get bored.

Here is my system in practice.

Saturday: Pushing and abs. Pushing is focused on the triceps, chest, and shoulders. Lifts include bench, shoulder and military presses along with a variety of incline presses and exercises that focus on isolating the triceps. I usually start heavy with benching, then work my way towards the shoulders and finally the triceps. Abs include a gambit of abdominal exercises including sets of crunches, sit-ups, twists, and stability training. I do 20 minutes of heavy pushing, 20 minutes of abs, then 20 minutes of lighter pushing. Usually by the 50 minute mark, I’m pretty worn out.

Sunday: Pulling and legs. Pulling is focused on biceps and upper back. Arm curls, lat pulls, rowing, all from various angles. Leg exercises include knee lifts, legs curls, calf presses, and the best of all, squats. If you’ve got to do just one lift, exercise your quads, as they are the biggest and strongest muscle in your body and the easiest to gain strength and mass with. Similar to pushing on Saturdays, I do 20 minutes of heavy pulling, 20 minutes of legs, and then 20 minutes of lighter pulling. On most days, I’m pretty wiped towards the end of the final period.

Weekdays: Running. My goal is to run five times a week. I’ve accomplished that goal maybe once. I run in the morning and early morning conference calls and meetings tend to prevent me from hitting the pavement more than 3-4 times a week. In the worst case, I’ll get in a pair of short jogs on the treadmill. In the winters I run on my treadmill at home for about 2 miles each session. In the summers I run outside and typically hit the 2-3 mile range. Running is my obvious weak point, and I am constantly aiming to improve my distance and speed. One technique that works well for me is interval training, where I alternatively jog for several minutes, then sprint for several more. The goal of running is to build up your cardiovascular system’s baseline performance and unless you’re getting your heart rate above 140 beats per minute and keeping it there, you’re probably not seeing much benefit. 10 minutes of hard running will do more for your heart and lungs than 20 minutes of jogging.

I’d also like to point out a few things that I don’t do. The first is stretching. While it is commonly accepted wisdom that you should never do anything rigorous without stretching first, I’ve yet to see any medical or scientific evidence backing up this assumption. So I never stretch, and I don’t seem worse for it. My warm-ups are simple and short: do a low-impact version of your target exercise first. That’s it. If my first lift is arms curls, and 90 lbs is my target, I’ll start with about 15 reps of 60 or 70 and then move on. When I run, I start out with a slow jog and work my way up. If anything, stretching adds the risk of overextending a tendon, while it seem to give me little or no benefit.

As I’ve stated earlier, I lift heavy. Lifting light weights has little benefit if you want to build strength. The only times I’ll break this rule is when I’m warming up or recovering from an injury, and testing the limits of what I can do.

Running and lifting with legs on the same day is also a no-no. Running and lifting builds different types of muscle fibers and everyone seems to think that doing both types of exercise too close together prevents the proper time for either type of fiber to develop properly. This makes sense given wheat I’ve read about muscle development. However, once I either run or lift with my legs, I’m just too tired to do the other.

I don’t do lower back exercise because I’ve got a pair of herniated discs. Once or twice a year they bother me, but for the most part they are not a problem. Nonetheless, I focus on strengthening my abs to offset any weakness in my back.

Total time spent per week? About 4 hours exercising. If you include driving to and from the gym, changing and showering, its more like 6 hours. You can fit that into your busy schedule too.