In 2003, Harvard Business Review published Nick Carr’s seminal essay, “IT Doesn’t Matter.” I remember that month well. The previous years of the PC boom, followed by the dotcom boom, had seen a tidal wave of money spent on technology. Much money was wasted on heavy investment in systems that either sat unused on a shelf, or ultimately were scrapped. To top it all off, the big “emergency” of the time, the millennium bug, turned out not to be as bad as everyone had feared. The time was rife for someone to declare the strategic irrelevancy of technology, and Mr. Carr stepped in and made the case. Because many executives desperately wanted to reduce technology spending at the time (in the aftermath of all that gluttony), reading Carr’s article was like receiving manna from heaven.

As a technology practitioner myself, however, it should surprise no one that I believe Mr. Carr to be wrong. Regardless of any biases I may have, the reality is that his argument contains several holes that have become ever more glaring with the passage of time. My intent with this article is to shine a light on what’s wrong with the “IT doesn’t matter” argument. I’ll even go further: I’d like to demonstrate why, now more than ever, investing—not just in technology, but in the intersection of technology and people—is the most important action that a company or organization can take.

The Company That Couldn’t Run a Second Shift

In my years as a technology consultant, I’ve certainly seen what happens when you don’t invest in technology. One client I vividly remember—we’ll call it Company X—had quite a conundrum. An amalgamation of nine different manufacturing organizations built up over time, Company X spent very conservatively on technology. When making an acquisition, Company X would do as little as possible on integration; for example, only enough to get the accounting systems and the order-entry systems sending orders to a central mainframe.

Over time, this management behavior at Company X resulted in a “Rube Goldberg” system requiring the work of hordes of COBOL programmers just to keep running. Overnight order processing required more than 200 manual steps. The maintenance cost of this Frankenstein’s monster of a codebase included at least 40 full-time COBOL programmers, a couple of dozen system operators, and who knows how much management hierarchy on top of all that. Company X was spending an estimated $15 million annually just to keep the system at its current level of functionality.

Unfortunately, that $15 million wasn’t even the most significant problem. When demand increased, Company X decided to run a second shift. The issue was that the system literally could not process orders in greater than about a 12-hour window. Moving to a 16-hour window, and eventually to a round-the-clock business, would require either radical changes to the old system or building an entirely new system—and it would have to match the quirks of the old system, in order to maintain compatibility with the nine other satellite systems!

Business analysts estimated that adding a second shift would increase gross margin in this low-margin business by around 3%, while increasing top-line revenue by over 20%. Moving to round-the-clock processing was also a precursor to being able to sell into new global markets, which would have increased top-line revenue even further.

Sadly, none of these happy improvements could come to pass for Company X.

The problems at this company were many, of which technology was merely one aspect. The deeper issue was that the operators and programmers who understood that mess of a codebase had a vested interest in keeping the current technology set running. But even if all those people were replaced, technical debt in Company X had built up over a long period of time, to the point that the company would need to invest around 2–3 times its annual profit in order to get out from under the load of technical debt.

In this culture of hubris, fear, and inertia, any new technology initiative to pay off the technical debt would almost certainly be killed. It was literally a recipe for company bankruptcy. When competitors are blowing you out of the water with 3% higher margins and 20% higher top-line revenue, taking that increased profitability and investing it into further productivity-enhancing technologies, it’s hard to see why “IT doesn’t matter.” If you’re a CEO in a company that can’t compete because of technical debt, you almost certainly will understand just how much IT does matter.

The rest of this article is available at Pearson Education’s InformIT website here.

It has been a long run, but after working in the following cities over the past 37 weeks:

• 10 weeks in Seattle
• 1 week in Los Angeles
• 1 week in Las Vegas
• 12 weeks in San Jose
• 6 weeks in Beijing
• 1 week in Orlando
• 3 weeks in San Francisco
• 3 weekends in places like Winnipeg and Minneapolis for Code Camps

… it appears as I will be back in Chicago – for at least a week! (I know… wow!).  The last one was a project we finished in 3 weeks out of 5 budgeted – which was a nice way to end what has been the most insane run of travel I have done in my career.  Now, I work in consulting, so I will likely be on the road again soon, but I thought I would take this opportunity to provide some thoughts on what works and what does not work when you are on the road as a traveling consultant.

Tip #1: When Possible, Get an Apartment

During my longer stints, in this year’s case, Seattle and San Jose, I managed to at least get corporate apartments that had fully supplied kitchens and laundry facilities.  While such arrangements are not practical for shorter projects (i.e. 2-3 weeks), I found that having such a place is a huge win/win for my clients as well as myself.  The cost of a corporate apartment is almost always lower than a hotel room – despite being far larger.  But more importantly, at least with me, is that I tend to prefer to cook my own food – which costs far less than spending a typical $35 per day on restaurants.  I often would have a net food cost – eating very high quality stuff, well under $100 per week, which would easily be blown on 3 meals during a week at a restaurant.

Probably more important though than the cost element is that I always felt healthier at the various corporate apartments.  I would routinely eat healthier when I prepared stuff myself.  It also kept my domestic rhythm going, as the practice of constantly eating out can make you stop remembering how to operate in a kitchen.  Same goes for having laundry facilities – something for me makes me feel normal if I have a daily routine, regardless of where I am, that involves taking care of myself.  Seems to make life, for me at least, feel more “normal” on the road.

Tip #2: Find the Local Bookstore (or Local “Whatever It Is You Like Doing”)

I am a bookworm – I read 3-4 nonfiction books a month, and probably skim through at least a dozen more.  Whenever I arrive in a new city, the first thing I do is find where the nearest good bookstore is, preferably an independent if I can find one, or the B&N or Borders if I can’t.  On the road, unless you are working 14 hour days (god help you), you want to find something to do with your idle time that isn’t work.

Tip #3: Do your Expenses Weekly

(note: I say this as I stare at a basket with 3 weeks of receipts in it…  ugh).

Expenses is a minor hassle if it is a weeks worth.  Much past that though and you a.) have what feels like an insurmountable burden in front of you and b.) you tend to forget things.  Just make it part of your routine to do them on Thursday night.

Tip #4: Avoid Too Many “Drinking Adventures” With The Team

This may be controversial – and thankfully, I learned this more in my twenties than in my far more tame late thirties I find myself in today, but man, does your effectiveness go down when you come into a client hung over.  I see people tend to drink more than they would at home when they are always going to restaurants, out with the team, and so forth.  After about 4-5 nights in a row of it, your liver will be screaming at you.  Do it, but certainly not to excess.

Tip #5: If You Have Family, Make Sure They Know You Still Exist

Another one where I all too frequently fall short, especially with west coast travel when I work too late and find myself home past bedtimes.  If you have kids, or a spouse, make sure they know you are around at least every couple days.  I swear, I got in the worst arguments with my spouse when I forget to call for a few days, and suddenly need to call because I need something “done at home”.  It is too easy to get lost in your project and forget to do things like that (at least for me)… but staying in frequent contact is critical if you have a family.

BTW, even if you don’t, tip #5 still applies to friends and extended family – though probably not at the same duration.

Tip #6: Stay Connected to your Tech Community

User groups mid-week in your home town are going to be hard to attend.  Make sure to use code camps or other weekend events to continue to stay connected and keep those networks intact.  One of the worst things you could do is take up travel, and then find that nobody remembers you 8 months later!

Tip #7: Use Travel to Expand Your Network

Find the local user group in the location where you are staying, and find a way to attend, or even better, contribute.  Travel, all things being equal, should be a net positive with regard to your network.

Tip #8: Airplane Time = Book Time, not Work Time or Internet Time

One of the worst developments I can possibly think of, at least for me personally, is the “GoGo Internet Service” that has been invading American Airlines planes.  Not that I am not thankful for innovation or what have you – but I use that time to take in materials that, well, take a long time to take in.  Whether it be books I have been wanting to read that require a good deal of concentration to successfully grok, or anything else that requires not being around distractions, leveraging airplane time to get those things done is one of the best ways to take advantage of that “temporary captivity”.

Tip #9: Spend at Least One Day On Location Doing “Touristy” Stuff

During my first four years as a road warrior, I visited places from Sydney to Madrid to New York and many places in-between.  Yet – I have never been to the Statue of Liberty, the Louvre, or other places I have perhaps walked by, but never really took in.  It took many years to remember that when being out here, I ought to use the opportunity to actually see a museum or do some of the things that, at the very least, give you interesting conversation fodder.  Getting to travel the world, and then promptly choosing to simply work on some 9th draft of a proposal in your room rather than experience some wonder of the world is, well dumb.  I know.  I have done it, and I still regret it!

Tip #10: Stay Healthy

Work out.  Eat healthy.  Read a balanced diet.  Don’t overwork.  Take care of yourself.  I know far too many people that burn out with this stuff because they forget that, even if you are on the road, you still have to take care of yourself.  Just because your employer is sending you somewhere does not mean they own you every hour of every day.  A burnt out consultant who goes through zombie like motions for a client isn’t terribly valuable to anyone, consulting firm, client, or themselves.

Happy Road-Warrioring!

Yes, I decided to make “Enron” into a verb in my latest InformIT article on technical debt titled “Don’t Enron Your Software Project”.

The idea is quite simple – if you are hiding technical debt rather than disclosing it to the project sponsor at the time of turnover of version 1, you are really doing something similar to what the guys at Enron did – namely, selling an asset that has hidden, undisclosed debts attached to it.

Read more here.

Sorry for lack of posting, but true to my moniker as a “Nomadic Developer”, I have been in China off and on (mostly on) for 5 weeks, working with a team on a project that we are doing at our ThoughtWorks office in Beijing.

Some thoughts so far. The first thought is how awestruck I am by the dynamism of China as a country. You always hear about it, but it is amazing to actually get to see it in person. Every time I go on a walk in Beijing, I am awestruck at just how vast of a city it is. Imagine something like the Chicago Loop, but it just keeps going and going, in all directions, for miles. That is basically what Beijing feels like to me.

However, the second thing I have observed – or really more just confirmed – is that China is really coming along as a place for software development talent. We all knew it would happen, I am just not sure I knew it would happen with such speed. During my trip, I paired with several developers from our office on our project, and truth be told, I am certain I learned far more from them then they could have possibly learned from me.

One example – and perhaps this is a ThoughtWorks thing generally – or maybe specific to China, is that on that project we are constantly pushing what we can do in our editor forward. Every time we repeat some action – such as finding usages for symbol – or anything else – rather than just muddle through using a mouse, we find a way to make it a keyboard shortcut. Pairing with this group has probably helped me increase my own developer productivity 2x, just in being around people who are constantly molding and navigating a codebase through ReSharper keyboard shortcuts (if you are not a programmer, ReSharper is a tool that adds a ton of productivity to Visual Studio, the typical tool people use to do .NET development).

For anyone who has some notion that “offshore” developers are somehow “lesser”, I can be sure that you can disabuse yourself of that notion immediately. I never learned so much in 5 weeks.

What does this mean for consulting in general? Well – I am becoming more and more convinced that, beyond the boutique stage of a consultancy (<10M in 1 or a small handful of cities working purely on founder relationships), if you have no global story, you are going to face an uphill battle. There is simply too much talent overseas, and the barriers to trade are simply too low, for you to be cost competitive on a large project. So much so that, if you were to ask me what skill you need to learn to keep your software development career humming, it would not be a programming language – it would be the Mandarin language.

The first article in my series about technical debt is up at InformIT, covering the concept of “Scrummerfall”, the insidious mixing of Scrum and Waterfall so you can pretend to be agile, but sadly, end up with simply a mess.

In the article, I introduce the persona of the “Hubricist”.  The Hubricist is the inner demon in all of us that just wants to seem “in-control”, and present an appearance that not only is everything “ok”, but that there is no risk, and progress on the project will be a nice, predictable, upward march of progress.

As much as I call out that persona in the article, recently, and even not so recently, I find this a persona that it is all too easy to fall to when dealing with the intersection of ambiguity and demanding customers.

In the best of all worlds, we can all be frank about how progress on a project is going. The problem is – even on a well intentioned team with good management support and everyone “on board” for doing “full agile” (whatever that means), you cannot escape the fact that we are all human.  No matter how agile you are, chances are, if you are human, you would rather not have confrontation than have it.  It is simply easier not to deliver a hard message – or sugar-coat one, than it is to deliver a hard message.  I believe the root of the inner Hubricist in all of us comes from the fact that we are human, and the Hubris of feigned confidence is simply a means of avoiding what is often a harder conversation than we want to have.  Lacking unlimited courage and “anything to lose”, it is inevitable that personal hubris on the part of those who report progress, reducing transparency.

So here is the reality – no matter who you are working with, there will always be a tendency toward Hubris.  The benefit of agile is not that it eliminates Hubris, but that it reduces the likelihood that it will be hidden.  If you are an on-site customer, chances are, you will have a better means to be a participant rather than an observer, which drastically increases the quality of information you receive.  You will see cards moving across the card wall directly.  If the team is healthy, you will constantly be seeing new bits of customer value demoed to you as they complete.

Better than that though, as an on-site customer, you have a chance to develop relationships with the team, which over time, increases the quality of communication.  As you gain a level of trust with the team, the team becomes more comfortable delivering both good and bad news.  To me, the very definition of a healthy consulting relationship is one where both customer and consultant are engaged in development of the solution on a day-to-day basis.  Avoiding Hubris requires courage, but it also requires trust, which is created through active collaboration.

As developers though – we have to constantly be on the lookout.  You have to become self-aware of when you are flying on hubris.  Success depends on habituating the practice of becoming real uncomfortable when making Enron style claims about progress.  It is tough, and sometimes, it feels risky, but in the end, replacing progress with Hubris is a devil’s bargain that only gives you – and your colleagues – more pain to be dealt with later.

On InformIT.com, I have published a selection of jargon terms from my book.  Some of the terms many consultants will be very familar with, some perhaps not so.

I am also taking this opportunity to announce that the next article series on InformIT will be diving into the topic of “The Economics of Technical Debt”.  As an officially certified armchair economist*, it is my duty to offer up my own analogies between bad code and bad economics in this series that (3 articles in, soon to be published in short intervals) skewers the notion that you can write bad code and simply leave the consequences for someone else.  Especially in consulting, where presumably you are trying to gain clients for the long term (i.e. long enough such that you can’t just walk after leaving them with a mess).

If you have not heard it already, I was interviewed by Carl Franklin and Richard Campbell on .NET rocks on the topic of technology consulting.  Specifically, we discussed how to avoid working for one of the “seven deadly firms” and musing about life as a consultant.  Check it out!