Thoughts on Offshoring, Pt III

Last time I wrote about my experience with offshoring on a large migration project. Interestingly, as soon as we moved our code into production I was moved over to manage a completely different group. As a result of a company reorg my job had been promised to someone else. For awhile, it looked like I was going to be laid off, but after checking around a bit I was able to snag a development manager position within a different group . Ironically this new position was within a bigger group, the rising star of my company in fact. So what had at first seemed like a terrible disaster was, in fact, a blessing in disguise.

My new team had been formed around the same time my old team had started implementing its offshoring stategy. While in my former group we'd charted our own path (to mixed success), my new group had followed the path laid by the executives within our company, both in terms of their choice of vendor (which was located in India), as well as the way they interacted with the offshore team members.

In fact, when the topic of using offshore as our primary development force (it had been use in a minor capacity for quite some time), started to be discussed in earnest, the decision of who would be our official "offshore partner" was one of the first topics to be discussed. I was told at that time that one vendor stood out because of the contract terms we had with them. Our contract with them contained clauses such that for we would levy "SLA" penalties against them based on the number of bugs in the code they produced. Additionally, if the code they wrote resulted in downtime of our system (which would result in SLA penalties for us) we would also charge them.

I thought this punitive model of development one was a terrible way to begin the relationship and said as much to my director. I really hold with the Agile folks about the absolute criticality of trust and collaboration. Of course, Agile doesn't hold any kind of monopoly on these things, but they do tend to put particular emphasis on these qualities. They seemed to disregard the importance of these things entirely.
"You wrote bad code, I'm going to smack your hand!"

But then the whole idea that "SLAs" in the contract were the reason we preferred this company was a a bit of smoke and mirrors. In fact, it was offhandedly mentioned in another meeting that our new offshoring company had a number of the same people on its board as our company did. When I learned that, I stopped asking questions. As with most business decisions (at least in my experience) it seemed to be based around how those at the top can put or keep th e most money in their own pockets.

The interaction model with this vendor was roughly as follows: we would maintain a staff of "development leads" on site. The leads along with our higher-level solution architects would be our only onshore development resources. The solution architect would interact with our internal program managers and customers to create a high-level solution. This solution would then be further fleshed out by an onsite development lead. The onsite development lead would then interact with a corresponding development lead on the offshore team, who would divy out this work to the developers on his side. This offshore team would also have their own managers to oversee the work who would interact with their counterparts on this side of the world.

I was extremely dubious about this model with its emphasis on "hand offs" and overlapping team members. More personally I was concerned this would mean I'd be on the phone with the guys in India at 3am every morning, and so on. This was not a pleasant prospect.

Interestingly, however, as part of the partnership we decided to bring over a number of offshore team members (mostly managers, a few devs) who bridged the gap between our offices. It is mostly these poor souls who now end up on the phone late every night with India, or having to convey information across to the team overseas.

What this has meant for me os that my interations with offshore have been relatively painless. The pain has largely been bourne by the onsite representatives of the offshore team. There have been minor issues I've had to deal with, but keeping track of resourcing, communicating, etc has been facilitated by the onsite members of the offshore team. Of course, the devs themselves still have to interact, but when we need to have calls between the teams they are done early in the morning our time. Sucks for the dudes in India, but relatively okay for us.

Also, surprisingly the model seems to be working. We've successfully launched a number of very large projects using it. That said, there is one huge caveat, and it's this:

I don't think it's saving us any money.

While the work churned out by the offshore team is reasonably adequate, it's very evident to me that there's a tremendous amount of overhead. I have almost 25 offshore resources reporting to me, logging thousands of hours. I guarantee you were not doing anywhere near that much real *work*. Of course, one example is worth a thousand words.

Recently, we had a fairly small project come in. We had one of the onsite dev leads provide an estimate. It ended up coming in around 4-5 days of effort. When we reached our formal kick-off, it was apparent we'd allocated 2 offshore devs full time for almost two weeks (so roughly 4 times the amount of time) to do the work. We also had hours and hours of time for multiple onshore and offshore managers. If you looked at the totals for hte project, it was absurd. All for four of five days of work. I've seen this now several times. The offshore resources may be a third as expensive, but they seem to take two times as many hours (if not more) to do the same work as our onsite resources. Then you have to factor in the fact that the onsite dev leads are spending 50-60% of their time simply overseeing this work, that you have to allocated hours and hours of offshore manager time, and it and pretty soon you've just blown way past the cost of the doing it onshore.

But the weird things is the company *is* saving money, so it's hard to argue. The problem is that there is no reasonable state prior to the offshoring with which one can compare costs. In fact, prior to the move to offshore the company was using almost 70% contractors, who were *extremely* expensive. Many of them weren't even good, some were atrocious. Even a crappy dev in such cases could cost as much as $210,000 a year. Of course they personally only saw a fraction of that. I managed a team of about 5 developers at one point, all contractors. My team cost over $1 million a year. If these guys had been FTEs, even with benefits the team would have maybe cost $600,000/yr Of course, the offshore stategy--even with it's tremendous inefficiency--is saving money over this insane policy.

Think of it this way, your nutty uncle who thinks he's the reincarnation of Elvis seems quite tame next to Charles Manson. Whether or not our offshoring strategy is saving money over a *rational* approach using great FTE developers is quite a bit more questionable to me.

Next article I'll wrap up with a summary of each of my encounters with offshore and the conclusions I've drawn from all of this.

The Triumph of Bureaucracy

I know I'd promised to finish up my mini-series on offshoring, but I like to be 'agile' with this blog. If a subject comes up in my day-to-day life that seems worthy of blogging I'd rather cover that and return to the more calculated subjects later. In any event, I've had a blog on my backlog about bureaucracy for some time now. Now, that entry is still yet to come, but today I will a share a minor case study in the subject while it still has some immediacy to me. My own version of thedailywtf if you will.

I work for a company that does regular work for cell phone carriers (most of the major ones in the US). Our software is used by millions and millions of people a day and we generally have very rigorous SLA agreements around uptime, etc. There are stiff penalities (I'm talking hundreds of thousands of dollears) if we fail them.

Understandably, this has lead to quite a bit of process around our release process. The typical process is the Pgm for a given project puts together a SiS (short interval schedule) for release of code. A typical high level schedule might look something like:

1. File formal RFC (Request for Change) to internal teams and carrier


2. Create SIS (short interval schedule) detailing timeline and steps of release, go/no go criteria, and latest time at which a rollback can occur


3. Formal review of the SIS with development team, as well as technician, release readiness analyst, and tier 3 support

The release themselves always occur within predetermine carrier maintenance windows, which differ slightly between carriers, but typically fall on one or two days each week, from about 11pm - 3am. The release itself usually looks something like this:

1. Send formal notification to carrier


2. Check that all production monitors are in green


3. Disable monitors


4. Pulling a subset of boxes out of a given VIP (for a subcomponent) and update it with new code.


5. Return the updates boxes to the VIP and remove the other boxes from this same VIP to complete the update.


6. Repeat steps 4-5 for each affected subcomponent


7. QA smoke test


8. Go/no go


9. Send formal notification of completion to carrier

Obviously, this level of rigor is understandable when you're touching something that gets millions upon millions of hits per day. The problem is when it's not appropriate.

Recently, I've been involved in a minor update to a simple testing site we've provided to one of our carriers. It's a legacy app written in PHP and MySQL, whereas our production code mostly runs on .NET and SQLServer. It's consists of about 2 production boxes, with a MySQL instance running on one of them. It hasn't been updated in about 3 years and is provided by this carrier to its handset manufacturers to do a first pass test on new handsets that are being released.

There are a trickle of requests per day (I'm talking like maybe 10 on a busy day) and it has little visibility wtihin the carrier. There are a few contacts at the carrier who use it but thus far they've been pretty amenable to anything we've suggested as they haven't seen an update to this app in over three years. Our current project mainly consisted in adding a few new tests and removing a couple that are no longer used.

We asked if we could release it in the day and they were complete agreeable to this, saying they just needed to notify their contacts at the device manufacturers. Seems like a no brainer, huh.

Except our customer PGM team responded by stating that it's a production box and so it *has* to be released in a nighttime release window. We need a bunch of people to come in from 11pm to 3am. The fact that we could even release it during the day without any impact to users (there are two boxes and only minor additions to some table structures that wouldn't impact the 4-5 end users) even if we *didn't* have the carrier send them an email saying 'Stay out of the system for an hour' wasn't acceptable.

So, instead of having an email sent, having people make some minor updates during the day, and doing what the logical thing, we're going to have all the process and bureaucracy of the type of release we'd have if we were impacting millions of users. Why is that? Because people are incapable of thinking critically, they are rigid. Logic is immaterial to a bureaucracy. At times i feel like I'm stuck in the film "Brazil"

Sam Lowry: Excuse me, Dawson, can you put me through to Mr. Helpmann's office?
Dawson: I'm afraid I can't sir. You have to go through the proper channels.
Sam Lowry: And you can't tell me what the proper channels are, because that's classified information?
Dawson: I'm glad to see the Ministry's continuing its tradition of recruiting the brightest and best, sir.
Sam Lowry: Thank you, Dawson.

This is simply one example, but next time I hear a question of why even simple things are so expensive, I'm goign to have to bite my tongue. I don't even care to argue anymore.

Thought on Offshoring, Pt II

My first experience with offshoring, about which I wrote a bit last time, was fairly typical I suspect: have the expensive architect-level folks come up with a high-level design, then throw it over the fence to cheap code monkeys to implement. This is the dream of the bean counters and like many of the most flawed ideas in software engineering, the concept attempts to draw (unsuccessfully) from other disciplines, in this case manufacturing.

In fact, when my current company started making a concerted push towards offshoring a number of us raised signficant concerns, to which one director said simply "Well, Apple had made it work with the iPod".

"Designed in California, Assembled in China" says the back of the iPod.

Well, if Apple does it, it must be a good idea!

Nevermind the fact that manufacturing is completely different from software engineering. I don't even think the most ardent proponent of waterfall design would argue otherwise. And this is the fundamental flaw with much of the thinking that comes from business-oriented executives: they don't understand how moving "thought work" to 3rd world countries difers from opening plants for the manufacture of textiles (The fact that the director mentioned above was someone who came from an engineering background made the statement even more baffling). The only way I can understand their decision making is if the truly believe software is nothing more than a widget to be manufactured.

About 9 months ago I found myself in charge of development for a fairly large scale migration project. It had already been underway for about six months when I joined the project. The staff was largely comprised of onsite contractors, but recently the decision had been made to start moving to offshore to save money.

A few of us in leadership roles on the technical quickly circled around to figure out what the hell this meant to us all. We had quite a few concerns, most of which centered around the difficulty we expected in communicating with non-native English speakers located in another timezone.

We knew our company had several choices for offshore companies. One of the three companies had locations in the Ukraine and India, the other only in India, and the last in Costa Rica. Given that Costa Rica was only three hours off our timezone, we decided this offered a clear advantage in communication, even if they cost a bit more. We successfully convinced those above us that the marginal additional cost was worth using this company for the project.

In addition to their location, we were also worried about the quality of the resources. Of course, we needed them to be competent programmers, but we also needed people who could communicate clearly via email AND via phone. We told our Director that we wanted to screen every potential resource. There was reticence on the HR end of things to do this but the team volunteered to round robin the screens so we could speak to every individual.

Obviously, flying these people out to do in person interviews was out of the question. Even more than that the sheer number of people we had to screen through was fairly signficant. So, we settled upon a brief 30 minute screen conducted via WebEx. Obviously, we'd never hire full-time employees this way, but in lieu of something better a basic screen where we asked some basic questions, could assess communication (and specifcally English as a second language) skills, and toss them a simple programming exercise was a huge step up from simply taking on whomever the offshore company threw us.

In fact, I found this accelerated screening process to be fairly effective as in most cases those who couldn't speak English at all or who were completely incompetent as programmers were weeded out in the first 15 minutes. And watching another programmer via WebEx while he programmed away in his IDE of choice on his *own* desktop was the truest test of a dev.

Ultimately, I'd say the resources we saw from Costa Rica were just as good as those in the US. There were plenty of incompetent people who the offshoring company swore up and down had years of experience, but then that's no different than my experiences interviewing good ol' Americans in onsite programmers. The simple fact is most professional "programmers" can't program. Nationality has nothing to do with it. Granted, some of the offshore resources had difficulty in communicating and in most cases this actaully resulted in us screening them out. The main thing I think it's important to remember *isn't* that the resources are from offshore. They are not intrisically less talented than Americans. No, the real problem is the genesis of the offshoring idea, the real motivation stems from a devaluation of the resources themselves. The qualitative aspect is forgotten, so the idea of *screening* these people, which almost no one would sanction when considering hiring full-time employees, seems somehow acceptable.

It isn't.

Now staffed, we had to decide if the offshore resources would be a distinct team or augment the onshore staff. Since even our onshore developers weren't completely clear on what we were building, it seemed like it'd be pretty difficult to"design" a solution then hand it off to a self-contained team to implement. There was going to have to be a lot of back and forth between onsite and offshore resources. That combined with the fact that our offshore resources did not have much experience with our code base led to the decision to augment our existing teams with offshore resources, rather than spinning up a siloed team.

As we made out way through the next 6 months of work, sprint by sprint, there were a few definite problems that arose. One of the biggest issues was that it was very difficult to have visibility into what the offshore team members were doing at any one time. Part of this was certainly attributable to the fact that We 3-4 Scrum teams with over 25 total devs. I'm not convinced the problem would not have also occurred with onsite devs. The difference was that if the offshore developers had been in the office, it would have been relatively easy to wander over to their desks, ask them they were working on, and sit them down next to someone else to assist. Doing the equivalent via email and phone calls ended up being quite difficult and if many cases, simply didn't happen.

One of the biggest issues with using the offshore team members effectively was that our implementatoin of Scrum was itself very poor. I triend to make sure we had some type of sprint planning with each of the teams and made every effort to include the offshore resources, but typically the offshore resources would not speak up at all during hte planning sesssions and were not really engaged. Once we'd figured out the work, it was frequently the case that it had been determined by the onsite dev leads and they didn't feel confident in giving it over to the offshore resources without having to do most of hte work themselves since it required too much explanation and back and forth. This often left our offshore resources with either nothing to do or stuck fixing trivial, low priority bugs which didn't really matter that much.

Additionally, even when we had very clear tasks to give to the offshore team members, many of them would quickly get stuck, requiring as much assistance from the onsite leads was it would have taken the leads to do the work themselves. Additionally, they rarely spoke up when they had no work.

Many of the problems in my view, weren't so much *because* of the offshore team members, it was simply that we did not have a good enough handle on our process to overcome the geographical distance. Additionally, while we had screened many of the team members, a good number of them were inherited from other teams that had previously used offshoring, and so language and skill issues were still present undermining hte confidence of the onsite devs in their offshore counterparts.

What was most interesting to me, however, was what happened as we started to 'ramp down' the project. As we neared the launch date for the project I was under immense pressure to roll off as many resources, onsite contractors and offshore developers, as possible and as quickly as possible. At the time, it seemed like the worst of all possible worlds as I was being asked to roll off team members when the project was at its more critical period. I thought it spelled doom for us.

In fact, somewhat countintuitively (though it shouldn't have been as it's the same principal described in the Mythical Man Month, by Fred Brooks) we started to see the opposite. As our onsite program managers were rolled off, one by one, and as we rolled off the those on the offshore team which seemed to be contributing the least, we started picking up considerable momentum.

It was not so much the fact that we were using offshore resources, but rather that, even in spite of our best efforts, we were carrying a lot of dead weight that weighed us down. This dead weight was present both onsite and offshore Towards the end when we'd rolled off all but hte very best of the offshore resources, we only had 3-4 offshore devs.

In fact, when we'd whittled our offshore resoruces down to about 3-4 from the original 15 we were left with very capable programmers. In fact, the best of them were the equal of any of our onsite devs. They thought critically, communicated status regularly, and took proactive action when necessary.

And now that the program managers who were managing the teams had been gone and they were put in the hands of myself and another technical person and we gave the offshore devs clear direction. Soon, we started to gain a good deal of momentum. And what had seemed impossible to do with 30 people, seemed now achievable with our team of 10.

And that, to me, is the biggest problem with offshoring. It many ways it originates from a mindset that denigrates the value of the individual. Often you'll hear it in the context of, we'll replace 10 full-time developers onshore with 30 offshore developers. But the *only* way it can be successful is if the same values you'd apply to your onshore developers are applied also to the offshore resources.

Like everything it's all about the people.

I guess this is part 2 of 4. Next time I'll write about the implementation of offshore with my current team, how it is working and NOT working. and in the final blog entry, I'll summarize my thoughts on where offshoring is useful, my own thoughts on how to help make it successful, and conclude.

Thoughts on Offshoring, Pt I

My first experience with offshoring came about 4 or 5 years ago. My company at the time had hired developers in Romania to rewrite our in-house log grinding software. I hadn't really been involved in any of it, but I was forwarded an email from our Director of Technology. The gist of the email was that the code made him weep. It had enough gems to keep http://www.thedailywtf.com/ going for a year.

One bit of code to calculate the current date that ran something like 80 or 90 lines of Perl. Apparently, this:

($DAY, $MONTH, $YEAR) = (localtime)[3,4,5];

was just too easy for our Romanian friends. The rest of the code was similarly awful. This set the tone for my thoughts about offshore, which could be summarized in a single word:
No

Of course, with however much vehemence I've argued against the offshoring trend, I'm usually not in a position to make the final decision. And the bean counters at the top always love it. So, I've had many subsequent encounters with it over the past several years. Some of it has confirmed what I believed then, but I've also had a bit of a reversal on some of my opinions, namely I now feel there is a (limited) place for it. I kinda feel about it how I feel about the 'goto' statement. Yeah, really fundamentally, I think it's a poor choice, but sometimes it's the best option. You really need to know *why* you're doing it, though.

The largest chunk of my experience has been over the past 8-9 months. I've worked extensively with two different offshoring companies, located in two different countries, and with very different implementation strategies. Both of them have had significant problems, but these experiences are also what have led to my somewhat more nuanced view of the subject.

There are some great developers offshore. Let's get that out of the way first. The best of the best overseas are just as good as the best of the best in the U.S. Now, I didn't originally feel that way. I used to think that the mindset of those trained overseas just lacked the creativity and incisiveness of those trained here in the US or Europe. But I really no longer think that's the case. The problem of course is this. It's immensely difficult to recruit and hire *great* programmers even when you're interviewing and working wtih them face to face. Compound that with the fact they are located in another time zone and it's near impossible.

Of course, you're also going through a third party to hire these guys. Their companies will always tell you how great every one of them is, but they are looking to make a profit and it's unlikely their criteria for a good developer is anything similar to yours. Hell, I don't trust most of the people within my own company to make intelligent hiring decisions when it comes to developers, so it's pretty much a lost cause when trying to bring on offshore resources. But from experience the *only* way you have any hope to make offshoring work is to have the exact same (if not higher) criteria for every one of your offshore resources that you'd have for your onsite devs. Really, given the communication barriers, the time zone differences, and so on they need to be *better* than the guys you'd have onshore. You *must* insist on interviewing every one of them. Yeah, it takes a lot of time, but to do otherwise will guarantee that you're dragging around a bunch of dead weight. That a huge problem onshore *or* offshore. Of course, the problem with this is that interviewing and having stringent criteria for your devs, flies in the face of the primary motivation for using offshore.

Let's not be coy. The *only* reason any company ever chooses to use offshore is to save money. That's understandable to an extent. The problem is the people responsible for the decision to use offshore are almost invariably those from a business background with very little technical knowledge. To them it's as simple as replace X programmers in the US costing Y dollars with X programmers in India costing Y/2 dollars. The idea that one *great* programmer will be ten times as productive as a mediocre programmer is completely incomprehensible to them. This is of course a problem with any large company where the senior leadership does not have strong technical backgrounds. They make decisions that simply don't make sense (I'll leave further discussion of this to another blog).

Of course, that's why it's so difficult to convince the people at the top that offshoring is not the clear win it seems to be. They just don't understand how much difference one *great* programmer can make. Making them understand that 3-4 great programmers who are working as a cohesive team can equal or exceed the output of 40 mediocre programmers in India is not something they can really wrap their heads around. I've tried to explain it many times, but (most) business people simply can't see past that bottom line on an Excel sheet.

I guess that'll wrap things up for now. Next blog I'll try to get into more details, talk about the two main strategies I've seen employed for offshoring and the relative advantages/disadvantages of each, as well what I feel are the necessary criteria to make offshoring work, and where it may actually be worthwhile.

The Man in the Mirror

*pause*
*deep breath*
My name is Zac and I'm a manager.

Sigh.

Way back when--about two years ago--being a dev manager seemed like a ticket to easy street. To be honest, I don't know that I was completely wrong.

Back then I thought anyone with 'manager' in his title was either ineffectual, dead weight or, worse, someone who got in the way of really getting the work done by bothering me for constant (and pointless) status updates. The latter was primarily the realm of project (or program, if you prefer) managers, for whom I had a particular distaste.

In contrast, my dev manager didn't seem to do much of anything. He'd send out emails about 'flow' or his random, half-witted musings. He didn't participate in any of my daily work, he wasn't responsible for any particular project or any real work other than going to meetings and if shit hit the fan, finding someone to blame.

The closest analogy I can of to how I felt at the time was like a man who's fallen overboard in the middle of the sea, treading water in the middle of the Atlantic, while wave after wave of work crashed down on my head, pushing me further down in the water each time, until finally I no longer had the strength to come back up for air. Being a dev manager seemed like an awesome gig compared to that.

Let me get this straight. I don't have any real responsiblities, I send out random dumb ass emails, and I go to a bunch of meetings. Oh, and I get paid a lot more money. Where do I sign up?

When I arrived at my current job, it seemed like I'd arrived in the promised land. I pretty quickly started having some personality conflicts with my manager (I felt he was micromanaging me), but ultimately I settled into my role fairly well. I've moved around a few times within the company now, managing various projects and groups, and at times I've felt as thought I contributed something worthwhile. Much of the time, however, feel like overpaid dead weight. I am part of the problem. I am no longer a doer, I am *sigh* a manager.

Of course, that was what I wanted wasn't it? And, on the whole, my own self-flagellation not withstanding, I'm still a hell of a lot happier than I was than I was at my last job.

Many would argue I can still be thoroughly technical and engaged at a low level and that it's merely laziness or incompetence on my part that prevents this. Or at least, my own internal voice whispers that from time to time. The fact of hte matter is, though, that I directly manage at least 7 development leads and a total of 30+ developers including offshore resources. It's really hard to go too deep into any one project or code change. Now and again, I involve myself a bit more deeply, but hell, half my days are spent in stupid meetings or updating "resource loadsheets" to appease my manager. There is no way I have the time to look at code much if I want to get my other work done.

As a technical lead at my former job, I attempted this, acting partially as architect, part as direct contributor, and partly as manager and in general it always meant that my managerial duties (which is where I should have been directing most of my energy) were done poorly.

I'm not directly responsible for much of anything anymore. The expecations placed on me are, in some sense, pretty minimal. That's a blessing on one hand. On the other hand, I still am a dev at heart and I have moments of self hatred for being in this position. But again, it's precisely the position I aspired to be in.

At the heart of this is a question about the value proposition of any individual as he moves up the corporate ladder. Or at least this is the case for technical people. It seems that the higher one moves, the more money he makes and the more "official" responsibility he has, but the less that person really does in terms of getting day-to-day matters taken care of.

To be fair to myself, however, I *do* contribute real value. I push the other managers to look at why they have so many meetings, I continually question whether offshoring really is saving the company any money. But nothing that I do gets those lines of code written. And that's the thing I struggle with. I suppose there is need for people like me in larger organizations such as the one I work within.

But I think there could stand to be far fewer of us managers at my company than there are. Just as I did when dev, I still like to think I contribute much more value than the 4 or 5 layers above me that seem to do nothing. But then again, I suspect some (all?) of the devs beneath me really question what I do and what value I'm contributing.

There is no easy answer to these questions. I don't find what I do terribly fulfilling, but I make twice the money I made as a dev and my life is relatively stress free. I work maybe 45 hours a week on average compared to my old job where 60 hours was a "light" week. But part of me longs to code again.

I think the only solution is to be part of a small company, a focused start up, where there is a relatively flat hierarchy, where the doers and the managers are the same people, where the people at the top are as technical as the people doing the actual work, and a director is never afraid to start coding away if necessary. The problem is those types of places usually are from most accounts high stress and low pay. And I've had my fill of that.

So, I guess, a manager I stay.

Buying a new computer

I don't buy new computers very often. Once about every 2-3 years seems to be my current pattern and since just about two years have passed, I suppose I was due. So, I bought a new laptop.

Now mind you, there was nothing fundamentally wrong with my current laptop. It's just BIG. I'd noticed a few co-workers carrying around spiffy little netbooks and now that I walk to and from work each day, my 7lb laptop starts to be a bit tiresome to carry home each day. I bought it about two years ago as a 'desktop replacement'. At the time my only computer was a huge Dell XPS desktop I'd bought in about 2005 to play games. It seriously is like 3 feet tall and weighs about 30 lbs, so the laptop seemed tiny.

The biggest motivation for getting the laptop was to checkout the code I'd been working on and get it running somewhere before I left my last job. Not with the intention of doing anything nefarious, but rather I find I can't remember jack shit unless I have example code where I did it before. Most of my coding is little more than copy-pasting, I guess. I'd probably struggle to put together "Hello, world!" in Java without some code lying around.

So, I started with the idea of getting a little 10'' netbook to carry around. A few people I know even have IDEs install and seem to be able to use them. But once I started looking at the tiny-ass screen I realized my vision was nowhere near good enough for that to work for any appreciable length of time. After reading a few reviews, I settled on the HP dv2. At 12.1 inches a little shy of 4 lbs it seemed portable enough, but could be used as my primary machine.

For the money (about $550 before taxes), I don't think you can beat it. 4GB ram, 260 GB harddrive, Athlon Neo, discrete video card, 12.1 WXGA.

But then my doubts started to gnaw at me. It didn't matter that the dv2 seemed to run Vista just fine (most netbooks can't). Even Eclipse booted up pretty quickly. Still, I started to obsess that the thing was just a little too big to carry around. I needed somethign smaller. The battery life wasn't quiet long enough at 3.5 hours. I need at least 6 hours. Oh, and it ran kinda hot. I don't want a hot computer! I also read comments about how the Neo, not being a multi-core processor, would bog down with multiple apps. I wasn't sure I noticed that problem myself, but I started to think maybe I did.

So, I took the damn thing back and went to lenovo.com to configure some crazy ass 12.1 inch x200 on Lenovo for over twice the money. It has a 2.4 GHz Core 2 Duo, 160 GB SSD HD, 6+ hour battery, and is marginally smaller.

Will I really see any benefit? I doubt it. In fact, the Lenovo won't be able to play games since it doesn't have a discrete graphics card. Some people have gambling addictions or alcohol, I have this OCD thing where I have to have the best available computer possible. Nevermind the damn thing will be outdated within a week of its arrival.

Thus far, I've tried to keep this blog fairly specific to the topic of software development and this is really a bit off topic. But thinking about my goofy need to have "the best", I can't but help draw some parallels to software development. Often we can get something that pretty much does everything we need with a fairly low cost, but then we start imagining needs
"Maybe the customer will change his mind and need this extra feature."
"Oh, we need to make sure that the screen loads in 0.2s rather than 0.3s"
"Oh, what if we need to store this extra data in the table, we shoudl design it so it's completely extensible and easy to update"

And quickly the budget and timeline have exploded, when in all liklihood the customer wouldn't have really noticed the difference and will never use the extra features that required so much additional effort. Of course, solving that problem is one of the mandates of things like Scrum and XP, but even when we use them I think engineers tend, by their nature, to gold plate things. Hell, the example of my laptop purchase shows how much even I can be driven by "emotion" rather than real logic.

I guess I should start saving now for my next computer. Two years isn't a very long time.

I enjoy acting, but what I really want to do is be a director!

If you've ever watched interviews with actors, it's almost invariable that at some point they'll utter the phrase "While I really enjoy acting, what I really want to do is direct." It's almost comical in it's predictability.

The thing is, programmers aren't much different. At least that was the case at my former job, where rampant title inflation meant that the title of 'Director' was roughly equivalent to a lead anywhere else. Of course, in that context, 'Director' meant 'Director of Software Engineering' or 'Director of Technology' or something. Forgetting nomenclature for a moment, though, there is still the common that many a programmer has toiled away in obscurity day and night only to suddenly see one of his co-workers elevated to a higher position for no discernable reason. Now at my old job a lot of it had to do with politics, but I even there it caused to me think about a few very basic questions, namely, what causes one person to rapidly ascend the ranks, while another toils endlessly in obscurity and how, as a manager, do you make sure that you promote people who are truly deserving and who don't merely appear to be deserving?

Most software engineers expect that promotions should be based on merit. Of course presumes that the world is a fair place, which I think most adults accept as a laughable assertion. I suspect there are no professions where promotions are based soley on merit. It's especially grating for hard working programmers it's usually not necessarily the most skilled or hardest working person who's promoted, but rather the one that *appears* the best.

Now, often such promotions will be chalked up to 'politics', and I think that's a fair point. As I said, at my last company most of the promotions were. In such instances, there is little one can do. At the same time, however, there is a ring of fatalism to such statements. By using 'politics' as an excuse you are essentially saying you have no power to affect change. The word also implies that those promoted are completely undeserving of promotion. I'll cop to the fact that they may not be the most deserving, but more often than not they are doing something right.

Having now managed a total of somewhere between 70-100 different individuals over the course of the last 3 years, I myself have "promoted" the wrong people a number of times. In most cases, I didn't even realize my mistake until it was too late. That probably says more about my own failings than anything else, but it is interesting to go back and ask myself why I made the decisions I did.

One telling example is from one of my more recent projects. It was a large migration effort from an existing software stack to a roughly equivalent one. There were a total of about 25 programmers, half onsite, the other half offshore, all formally reporting to me. We had about 3-4 Scrum teams. We had a few leads already established, but due to some reorganization of teams, we needed a few more. This is where I made some flat out bad decisions.

One of the new leads, whom I'll call Jason, was picked based on merit. By at least one of the senior programmer's accounts he was 'the best programmer on the team'. I heard some grumblings that he did things here and there that were a bit goofy, but for the most part everyone agreed he turned out fairly solid code.

Of course, I thought giving him more responsiblity was a no brainer. But soon questioned my decision. He could not delegate work to others, instead having to do it all himself. He would make commitments to a given schedule, saying it wasn't a problem, only to later reverse himself and start saying he had too much on his shoulders. I never had any faith that when he said something was a 'day from being done' that it was anywhere near complete. He took a great deal of time escalating minor issues to me that I thought he should be handling. When the project ended he left, of course, but had he stuck around his performance would have caused me to put him back in a purely dev role and remove the extra responsibility from his shoulders (i.e. I would not have formalized his promotion).

Now the other lead, who I'll call Scott, was mostly self-selected. He had a military background which tended to make him a bit more authoratative, more familarity with Scrum (which was generally lacking on all teams), and he seemed to 'know what was going on'. When I asked him how things were going he gave compelling, concise answers. He made decisions on his own rarely escalating to me, help coordinate onsite and offshore resources, and I largely stopped worrying about his teams progress. I *trusted* him.

The thing of it is, though, Jason (though hardly a leader) was less of a disaster than Scott. From his utter panic, constant escalations, and inability to meet targets, I *knew* his stuff was in a bad shape. He *was* a failure as a leader, but I *knew* it and so could work to mitigate it. In constrast, I didn't know Scott had been a disaster and his team was totally off track until *after* he had left. Where he had been saying 'things are almost done', they were not even close. Looking more closely at his work, he had made bizarre arbitrary decisions that according to him were 'best practices', yet flew in the face of every internal convention established within the company. What's most interesting to me is that he had the classic qualities one looks for in a leader, the type of personality traits that cause one to be promoted. The problem was that his underlying decision making, the real crux of what he was doing was complete crap.

I'm not sure I have a great answer as to how to ensure those promoted are the right people. The obvious answer is to is to look closely at the work the person is doing, but a large portion of hte time those making decisions about promotions don't even have to the techincal background to make such an evaluation. Even for people like me, though, it's really easy to say that you'll look carefully at every line of code and every decision and quite a bit harder when you are managing large teams. When you have 20 or 30 people reporting to you on multiple teams, you have to choose where to direct your efforts or you'll get nothing done. When someone seems to be making the right decisions, who's reporting good progress, one is inclined to accept it. In the example mentioned above, I felt all my time needed to go to managing Jason, whereas Scott had things under control. I thought if I spent time on Scott, I wouldn't have enough to keep Jason on track. Scott made my life easier, whereas Jason ate in my time day after day. It's only natural that a manager will look kindly on those who seem to make life easier.

As for what you yourself can do to help raise your visibility, they're again simple things on paper. Don't escalate every tiny issue to your manager. Follow through on your commitments. Don't get angry (this has always been a big one), when people seem to make unreasonable requests, and try to say 'I'll see what I can do'. And more than anything else, market yourself. If you're not making others aware of your accomplishments, it's unlikely anyone else is. That's not to say you should negate what your team is doing, but an offhanded word here and there goes a long way. You may feel like a car salesman, but no one will look out for your best interests but you. Again, as with all things, on paper this stuff is easy.

In the real world, it's tough as hell.