So let’s turn back the clock through the mists of time in the years leading to the Agile Manifesto in 2001. Back when this movement started, many of the “reasons for Agile” just seemed very intuitive. People over process? Sure. Responding to change versus following a predefined plan? Common sense. On the surface, few people would disagree with the assertions made in the Agile Manifesto. But is that enough? Can you following the Manifesto—do it all by the book—and be guaranteed to create software that delivers economic benefit? No. By itself, Agile doesn’t lead to business value!

How Can By-the-Book-Agile Fail?

Let’s be clear. With its increased collaboration with the customer, more frequent releases, and increased engineering and testing discipline, Agile makes delivering value more likely. It’s certainly a vast improvement over multi-year “too big to fail” Waterfall software projects. But even if you do everything right, even if you have the best practitioners in the world building your product, you can still create a product that fails to make money.

Agile—and here we mean the kind that includes the right engineering practices, such as test-driven development (TDD), pairing, SOLID principles, automated acceptance testing, and continuous integration—will ensure that you create a product that works…in the lab, at least. However, despite your best efforts, you might build a very functional eCommerce site that tries to sell something that nobody really wants. Or you might build an internal application that can’t go beyond the lab because the operations people can’t support it in production. These issues—and many other things outside direct control of the team practicing Agile—can thwart even your best efforts.

Article continues here

It’s amazing how things change in ten years. Once considered a methodology preferred by software developers because it “helped them avoid having to do status reports,” Agile has now gone beyond its original remit as a software development method. The word Agile, in many places, has become nearly synonymous with the word Good. As flattering this must be to the original founders, it probably means it would be wise to think, very candidly, whether Agile—as in Agile Software Development, or a broader Agile Enterprise—is really something that your company can achieve.

Read the rest of this article at InformIT here.

As it seems to have turned out, we are now in the Revenge of The Nerds economy. Despite 9%+ unemployment in the general economy, overall unemployment for software engineers is a tad below 5%. But this data, which is compelling enough, does not tell the entire story.

The bigger story is around what kinds of things are seeing investment. There is talk of another bubble right now in technical startups. If you are a technology based startup that has reached “Ramen Profitability”, you will almost certainly attract capital. Things are now even getting to the point where we are seeing companies that lack profits going to the IPO market (think Pandora and Groupon) – something that has been out of vogue since at least 2001. One could make the case that we will soon cross the line where it is easier to get a startup funded than it is to get a jumbo mortgage.

If you work in tech, there is a good chance you are feeling this, at least if you are currently employed and working for an employer that has some level of visibility. If you work for Google, Facebook, or some other high tech company, you likely do not have to work that hard to get a new job offer. Notwithstanding the cruel irony that people who are unemployed are often being systemically discriminated against, the job market for really good, currently employed software developers is as robust has it has been in 10 years.

So if the nerds are all right, mostly, what about the jocks? What occupations did they end up in? While some of them may have made it to the NFL as professional football players, most others end up in spilling into the general job market. While the stereotype is that jocks end up in menial jobs, construction, or manufacturing; research being hard to find, my own experience of knowing several such folk points to careers tending to be sales, low-end finance (think mortgages), real estate, and personal training. Given, a sample size of a couple dozen doesn’t really prove anything. However, if one did extrapolate, one could come to a conjecture that while “jocks” for lack of a better word, do not do worse then average now, the nerd/jock investment and employment dynamic has changed.

Why the change? Now that simply taking big leveraged risks with a big pile of money isn’t in fashion (i.e., as it was before the global financial crisis), you need advantages from superior intellectual capital in order to sustain a higher than mean return on investment. Why not in fashion? From 2003-2008, it was accepted that financial engineering was the way to riches. If you only structured your collateralized debt obligation in the correct way, you could invest at 40x leverage and still retain a AAA rating on your debt. Financial engineering gave you higher profits under such a regime than traditional “engineering engineering” could provide. So money flowed into CDS structures and away from the nerdy parts of the economy that invents things.

So now we find ourselves in an economy where capital flocks to things like Pandora, Groupon, Facebook, Linkedin, and other things that, at their core, have interesting algorithms inside them. And we have a situation where if you are a developer capable of writing an interesting and valuable algorithm – or helping a company scale out a system that leverages one of these inventions, you are in high demand.

Good thing for the nerds. What this means for everyone else remains to be seen.

So I have a humble request.  First of all, I think we can just start assuming that if you have a goal that requires more than, say, the amount of money you spend annually on copiers in a small office annually, you are going to need upper management support.  Especially if it is going to change the business.  If you are engaging on a “change the company for the better initiative”, getting upper management support is basically the first, and one of the easier, steps.

• The real hard stuff isn’t upper management, it’s middle management.  Upper management does not usually have their empires or jobs threatened by a significant IT initiative.  Middle management, on the other hand, often does.
• The day to day impact of a large programme on the lives of upper management is comparatively low.  Most of the time, they can get on with their normal duties and continue to operate at the “strategic” level rather than hands on.  Middle management, on the other hand, often has to expend significant time, energy, and political capital in the programme in order to make sure it works.
• The numbers of people in upper management are lower, well, because they are upper management.  You can more easily get a small number of people on the same page.  Middle management numbers are much higher, and making the politics of middle management engagement much more difficult.
• Various groups in middle management that are impacted unevenly create opportunities for internecine politics to enter the scene.  Even if you get middle management engagement, keeping it is a much more difficult chore.

There are all sorts of things you need in order to make a large programme of transformational work successful.  Upper management support is just the “table stakes” – the ante for getting to the table.  Getting support of middle management, and getting past the many roadblocks they can put in your way, is much harder, frequently underestimated, and frankly, in my experience, much more of a project success factor.

Lets start with some test cases:

module UnionTypeStructuralComparisonTest
open StructuralTypeSimilarity
open NUnit.Framework

type FooBar =
 | Salami of int
 | Foo of int * int
 | Bar of string

type FizzBuz =
 | Toast of int
 | Zap of int * int
 | Bang of string

type BigOption =
 | Crap of int * int
 | Bang of string
 | Kaboom of decimal

type Compound =
 | Frazzle of FizzBuz * FooBar
 | Crapola of double

[<TestFixture>]
type PersonalInsultTestCase() =

 [<Test>]
 member this.BangCanGoInFooBar() =
 let bang = Bang("I like cheese")
 Assert.IsTrue(bang =~= typeof<FizzBuz>)
 Assert.IsTrue(bang =~= typeof<FooBar>)
 Assert.IsTrue(bang =~= typeof<BigOption>)

 [<Test>]
 member this.KaboomDecimalDoesNotFitInFizzBuz() =
 let kaboom = Kaboom(45m)
 Assert.IsFalse(kaboom =~= typeof<FizzBuz>)

 [<Test>]
 member this.SomeStringCanBeFooBar() =
 let someString = "I like beer"
 Assert.IsTrue(someString =~= typeof<FooBar>)

 [<Test>]
 member this.SomeFoobarCanBeString() =
 let someFoobar = Bar("I like beer")
 Assert.IsTrue(someFoobar =~= typeof<string>)

 [<Test>]
 member this.SomeFoobarTypeCanBeString() =
 Assert.IsTrue(typeof<FooBar> =~= typeof<string>)

 [<Test>]
 member this.CompoundUnionTest() =
 let someCompound = Frazzle(Toast(4),Salami(2))
 Assert.IsTrue(someCompound =~= typeof<FooBar>)

To make this work, we are going to need to implement our =~= operator, and then do some FSharp type-fu in order to compare the structure:

module StructuralTypeSimilarity

open System
open Microsoft.FSharp.Reflection
open NLPParserCore

let isACase (testUnionType:Type) =
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.exists(fun u -> u.Name = testUnionType.Name)
let caseToTuple (case:UnionCaseInfo) =
 let fields = case.GetFields()
 if fields.Length > 1 then
 fields
 |> Array.map( fun pi -> pi.PropertyType )
 |> FSharpType.MakeTupleType
 else
 fields.[0].PropertyType 

let rec UnionTypeSourceSimilarToTargetSimpleType (testUnionType:Type) (targetType:Type) =
 if (testUnionType |> FSharpType.IsUnion)
   && (not (targetType |> FSharpType.IsUnion)) then
 if testUnionType |> isACase then
 let unionType = testUnionType
  |> FSharpType.GetUnionCases
  |> Array.find(fun u -> u.Name = testUnionType.Name)
 let myCaseType = caseToTuple unionType
 myCaseType =~= targetType
 else
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun case -> (case |> caseToTuple) =~= targetType )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and UnionTypeSourceSimilarToUnionTypeTarget (testUnionType:Type) (targetUnionType:Type) =
 if (testUnionType |> FSharpType.IsUnion)
  && (targetUnionType |> FSharpType.IsUnion) then
 if testUnionType |> isACase then
 targetUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun u -> u |> caseToTuple )
 |> Array.map( fun targetTuple -> testUnionType =~= targetTuple )
 |> Array.exists( fun result -> result )
 else
 testUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun case -> (case |> caseToTuple) =~= targetUnionType )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and SimpleTypeSourceSimilarToUnionTypeTarget (testSimpleType:Type) (targetUnionType:Type) =
 if (not (testSimpleType |> FSharpType.IsUnion))
  && (targetUnionType |> FSharpType.IsUnion) then
 targetUnionType
 |> FSharpType.GetUnionCases
 |> Array.map( fun u -> u |> caseToTuple )
 |> Array.map( fun targetTuple -> testSimpleType =~= targetTuple )
 |> Array.exists( fun result -> result )
 else
 raise( new InvalidOperationException() )

and SimpleTypeSourceSimilarToSimpleTypeTarget (testSimpleType:Type) (targetSimpleType:Type) =
 if (testSimpleType |> FSharpType.IsTuple) && (targetSimpleType |> FSharpType.IsTuple) then
 let testTupleTypes = testSimpleType |> FSharpType.GetTupleElements
 let targetTupleTypes = targetSimpleType |> FSharpType.GetTupleElements
 if testTupleTypes.Length = targetTupleTypes.Length then
 let matches = Array.zip testTupleTypes targetTupleTypes
 |> Array.map( fun(test,target) -> test =~= target )
 not (matches |> Array.exists( fun result -> not result ))
 else
 false
 else
 testSimpleType = targetSimpleType

and (=~=) (testObject:obj) (targetType:Type) =
 let objIsType (o:obj) =
 match o with
 | :? Type -> true
 | _ -> false

 let resolveToType (o:obj) =
 match objIsType o with
 | true -> o :?> Type
 | false -> o.GetType()
 let testObjectIsAType = testObject |> objIsType
 let testObjectTypeIsUnion =
 match testObjectIsAType with
 | true -> testObject |> resolveToType |> FSharpType.IsUnion
 | false -> false
 let targetTypeIsAUnion = targetType |> FSharpType.IsUnion 

 let resolvedType = testObject |> resolveToType

 match testObjectIsAType,testObjectTypeIsUnion,targetTypeIsAUnion with
 | false, _, _ -> resolvedType =~= targetType
 | true,true,false -> UnionTypeSourceSimilarToTargetSimpleType resolvedType targetType
 | true,false,false -> SimpleTypeSourceSimilarToSimpleTypeTarget resolvedType targetType
 | true,true,true -> UnionTypeSourceSimilarToUnionTypeTarget resolvedType targetType
 | true,false,true -> SimpleTypeSourceSimilarToUnionTypeTarget resolvedType targetType

Getting this to work seemed harder than it should.  While my tests pass, I am sure there are both cases I have not yet covered, and probably some simpler ways I could accomplish some of the same goals.

While this is a work in progress, if anyone has any thoughts for simpler ways to do something like this, I am all ears.

Dependency Injection

Dependency injection is a great technique for being able to manage coupling.  At least it is in practice.  But there is nothing that would stop you from using dependency injection to, say, create a giant class and inject thirtyteen-hundred dependencies in it and giving yourself a maintenance nightmare.

What is important about dependency injection, is that it makes you think about dependencies. When I am writing code, I want creating a dependency from one class to another to hurt.  Not a lot, but enough that it makes me put an entry in a file somewhere – be it an xml config, or a module, or something.  A DI tool that wires everything up for me without me having to explicitly think about it each time – well, that is to me like an HR management tool that does not have an “are you sure” prompt on the “fire employee” button.

Continuous Integration

Continuous Integration tools do some nifty things, one of the most important being providing some visibility to the state of the code.  When properly implemented, the benefits are pretty staggering.  However, in my experience, one of the most important benefits is that Continuous Integration forces you to think about how to automate the deployment process. You can’t continuously integrate if some person has to flip the bozo bit in order for the build to work.  CI promotes a model that makes tools that require human intervention to install seem obsolete.  I can’t see this as a bad thing.

Functional Programming

Most anyone who knows me in a professional context knows I am a big fan of functional programming.  I have grown to like the syntax and expressibility of languages like F#, and there are a great many reasons why the language is important.  But to me, the most striking is that functional languages make you think long and hard about state.  You can do state in F# (through the mutable keyword) – even in pure functional programming languages like Haskell if you implement a state monad.  But the important thing here is that you have to do significant work to create state in these languages.  That leads to choices about state that tend to be more mindful than in languages where state is the default.

I could talk through more examples, but I think you get the picture.  The opposite tends to hold true as well – my main issue with a technology like ASP.NET Webforms is that it makes certain things easy (ViewState, notably) that it should not, in order to help you avoid having to think about the fact that you are running an application over a stateless medium.  When you are considering a new technology that is emerging – don’t think features, think “What choices is this technology forcing me to make?”

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.

Do you champion change to help reduce such technical debt? You may eventually be rewarded for your foresight—but meanwhile the risks of championing change are very high. If you want to write maintainable software, a multitude of barriers stand in your way. When you admit that you can’t state with absolute certainty what will be delivered, do other people paint that disclosure as an admission that your team lacks discipline? Do your developers who have not yet tried pair programming or test-driven development reject those techniques without ever really attempting them—just because they’re new and initially uncomfortable?

Previous articles in this series have explored the problem of technical debt, the ultimate costs of this problem, and how methods that work only at surface levels stifle the possibility of changing to something better. In this article, we’ll consider why these problems affect our technology organizations in the first place—how technical risk factors into the technical debt that plagues the software industry.

Taking Down the Hubricists

I defined the term Hubricist in my article “Scrummerfall: World’s Worst Software Development Methodology.” The Hubricist attempts to impress those above him by replacing real data about the real velocity of the project with hubris. What the Hubricist lacks in substance, he makes up in bravado: “Yes, we will hit the deadline. Yes, you will get all the features!” When neither happens, developers are blamed for not working Sundays in addition to Saturdays, and careers are derailed in the aftermath.

Why is the Hubricist so opposed to change? For a moment, try to think from his point of view. Somebody (perhaps it’s you) comes along and trots out this methodology that promises transparency, particularly with regard to quality and technical debt. Is this methodology good for you, Mr. or Ms. Hubricist? Where would you fit into a regime that values results over bravado? Results-oriented management might not allow you to blame other people when things go wrong. If customers see that developers are making progress on a daily basis—working hard, but not at the unrealistic rate of progress you promised in order to sell the project, where does that leave you? Exposed, having made a lot of promises that can’t be kept.

With this kind of mindset, it should be no surprise that Hubricists try to block adoption of Agile methodology, or any other system that adds transparency. Remember the scene in The Wizard of Oz where the curtain draws back to expose the little man behind the booming voice? When the Hubricist perceives the potential for exposure, he plays the FUD card: fear, uncertainty, and doubt. He walks around claiming that Agile isn’t disciplined, that it’s about developers who don’t want to write documentation, that it’s advocated by teams that don’t want to be held accountable for results.

What can you do to counter the Hubricist’s claims?

• Point out that Agile teams actually tend to produce far more useful documentation than other methodologies can. These are real showcases that demonstrate working software, versus mere status reports with vague claims of xx% complete, based on nothing but self-reported guesses.
• Note that accountability for results must be based on a solid track record of delivery. Is a high percentage of the development budget spent on software maintenance costs? Past results don’t allow you to claim “accountability” for the future unless you have changed those statistics.
• Show a real Agile team. Show stakeholders the daily artifacts of story cards moving from backlog to completion. An Agile team room is an active place, where collaboration tends to be visible and signs of progress are frequent. Compare this to a typical cube farm in a waterfall project.

The rest of this article can be read here.

Welcome to ThoughtWorks, and Welcome to Silicon Valley!

Fast forward to today, and this same person, who I remember having a passion for functional programming and math that far exceeded anything I could muster up, is now one of the people behind FlightCaster – a service that uses functional programming (using Clojure and Hadoop) to implement a predictive algorithm that can tell you – with far more accuracy than the airlines – when your flight will arrive!  Being the cynical skeptic that I tend to be, I really did not believe it until I started using the service myself.  While I am only two flights in, the results are very promising.

To sum up what it does, the service uses 10 years worth of flight data, along with a certain amount of statistics wizardry that I almost certainly don’t understand, to correlate various events (plane arrival times, weather, etc.) to instances where delays occur.  More to the point, when I think of what business intelligence should be, what FlightCaster does seems far more interesting to me than what I have seen in most vendor presentations.  This is what leads me to the idea that BI comes from an idea about how correlation might occur, combined with technical folks who understand statistics and know how to harness data to do analytics.  It almost certainly never comes along because you install a tool.

So if that is where BI comes from, what is the most ideal toolset for helping to realize it.  There are no shortage of vendors who will try to sell you something that will lock you into their stack.  Or sell you some sort of whiz-bang UI that convinces you that you can go cheap on people so long as you just have good tools.  A typical anti-pattern is that an organization will buy the tools, then basically use them to do reporting against a data warehouse and post some simplistic results to some dashboard.  Something that, when you get down to it, you could have done without the tools, and probably without the fancy dashboard, at far lower cost using simpler tools.

This is especially true today.  We now have functional languages, equipped with great math and statistics libraries, that are for the most part mainstream (Clojure and F# come to mind).  We have open source tools like Hadoop (no more big expensive software) which make this stuff work in distributed computing environments that make it so you can leverage commodity hardware (no more big expensive iron).  If FlightCaster, a service that is as innovative as anything I have ever seen in the BI space, probably moreso, runs on this kind of stuff, it is probably good enough for what most companies would ever call their own BI efforts.

So what are the barriers to this?  One barrier I have encountered is that there is a bias against BI efforts that require “programming”.  I once gave a webinar about this topic to a group of CIOs, Consulting Executives, and BI product vendors.  One of my points was that the most useful BI efforts would require a technologist.  One guy in the crowed literally booed.  There is literally a subculture in the world of BI that thinks if you have to have someone program something, you have done a bad job.  Why this is the case I can’t be certain, but given that there are corners of the IT world that see programming as something to be avoided, it is not entirely surprising.

Another barrier is that there are more than a few CIOs or “Directors of BI” who are charged with the task of implementing a BI initiative, but have no clue where to start.  They know they need it, and that is as far as it goes.  Opportunistic salesperson comes on the scene, sells the SKU, and suddenly, we have a BI initiative made mostly out of shelfware.  It does not help that the world of “big database” (think IBM, Oracle, Microsoft) sells a database product that is largely a commodity without some proprietary BI extension which is usually added for differentiation purposes.  With a database software sales force already ensconced in the world of the enterprise CIO, it should suprise nobody that there are folks who think you need IBM, Oracle, Microsoft, or some other product to do BI.

I am here to say hogwash.  You don’t need any of that stuff.  The tools are here, they are free, and they have clearly done BI on a scale grander than most BI efforts I have seen inside most corporate IT.  What you need is a decent use case (tell me when my flight will arrive), that is solvable by a combination of data, math, and organizational will.  Do that, and you will have Business Intelligence.

• 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!