Thursday, April 5, 2007

Why You Have To Work As A Consultant

Pat Maddox says you have to work for a startup. He's wrong.

Actually, he's right. You do have to work for a startup, at least once. But he's also wrong. You have to do other things as well. One of those things is working for a consulting firm, or going into business as a consultant yourself, or both.

You will learn how vastly different beautiful code is from useful software.

You will learn how much more useful listening to your users is than visualizing something cool.

You will discover the compelling business reasons for agile software development, and you will do it, at least once, by having to dig yourself out of a pit you created by failing to understand what agile really meant.

You will come to see business processes as programs run not within computers but by groups of people.

You will have time off on the weekends and you'll be able to have a life.


  1. I've been thinking a lot about this recently.

    In my area (Grand Rapids, MI), there are many consulting shops, but very few shrinkwrap software companies.

    I believe it was Joel Spolsky who said that the best place to work if you're a programmer is an actual software company.

    I was resisting going down the consulting route, but I might have to eventually go that way considering the dearth of software companies in Grand Rapids.

    So, Giles, you obviously like working for a consulting firm, but have you ever worked for a software company? If so, how would you compare the experiences?

  2. Actually I don't work for a consulting firm at the moment. I'm doing consulting on my own.

    I don't think I've ever worked for an actual software company. Definitely not in the sense of shrinkwrap. It depends if you count Web applications as software.

  3. I take my definition of shrinkwrap software from Joel Spolsky's "Five Worlds" article:

    Shrinkwrap would include commercial web applications like Basecamp and Salesforce.

  4. You will learn how vastly different beautiful code is from useful software.

    Yep. Been there, done that. It's so disappointing when you discover this, though. In a previous blog post of yours on refactoring I commented about a project where I had a chance to really refactor a large chunk of code that was littered with cut-and-paste code. I said I made it "a thing of beauty". It worked as well, though not like the original version. Part of the tool I was working on was a language interpreter. The parser was implemented using standard C functions. I wanted to use lex and yacc instead. There were some things the original script language did that were not compatible with yacc. So with my boss's permission I got rid of those features. After getting all this done I was so proud of myself. Then our sales guy came along and wanted to use the tool I had been working on for a demo for a client. The thing was he needed the language features we took out. My "thing of beauty" was worthless to him. I ended up giving him a working copy of the old version. Big lesson learned: Users don't care about code or code design. They care whether it does what they want. Period. It wasn't that all my refactoring work was worthless. The mistake was we reduced functionality in order to achieve some of the goals of the redesign, and thought we could get away with it.

    I've pretty much worked only for consulting companies. One functioned kind of like a software company. They didn't sell shrink-wrapped software. They had some "secret sauce", proprietary technology that they incorporated into each custom project we did though. They also developed a framework that they used to build custom apps., which could be modified by programmers on the client end. The product was a bit like what Dundas sells: a collection of UI and data components that had some flexibility and snapped together well. I didn't work on the framework.

    I've had a little startup experience as well, though it's nothing to write home about.


Note: Only a member of this blog may post a comment.