DaedTech

Stories about Software

By

The Journeyman Idealist: Architect of Programmer Paycuts

A couple of months ago, I mentioned that I’d be featuring more cross posts so that I could concentrate on my book.  I’ve lived up to that, mixing in the occasional answer to a reader question with posts I’ve written for other sites.  I haven’t queued up a good old fashioned rant in a while, but I think it might be time.

I want to start talking about topics from the book, and this particular topic, the “journeyman idealist” has relevance to a number of different, random conversations I’ve heard of late.  Don’t worry if you don’t know what “journeyman idealist” means — you shouldn’t because I made that up while writing my book.  And I’ll get to that and to our self-defeating pay tendencies a bit later.

Hourly Billing

Recently, I have consumed a great deal of content related to freelancing, consulting, and billing models.  This includes the following items, for those interested.

As I fall further into this rabbit hole, I become increasingly convinced that billing by the hour for knowledge work is a pile of fail.  Jonathan Stark of “Ditching Hourly” makes the case more eloquently in this episode, but I’ll offer a tl;dr.

Let’s say that a prospective client comes to you and says, “I want you to build me a website.”  Great!  Let’s do some business!

HighFive

Hourly Billing as a Zero Sum Game

At this point, you begin to think in terms of cost and how high you can go above it.  For the purpose of your business, this means “what is the minimum amount for which I will do this project?”  The client begins to think in terms of value and how far they can go below it.  For them, this means “what is the maximum amount I can pay and still profit?”  Perhaps you won’t build the site in question for less than $10,000 and the client needs the figure to be less than $100,000 for the venture to bring a profit.  Thus if you agree on a price between $10,000 and $100,000, you both benefit, though the amount of the benefit will slide one way or the other, depending on how close to each end point you settle.

If you were selling websites as commodities, you’d haggle, then settle on price, as with a used car.  But building custom websites by the hour differs substantially.  In that world, you strike a deal without agreeing to price.  You just both hope that when the dust settles, the price tag falls in the range of mutual profit, and no lawsuits commence.  But within that range, each party hopes for a different end of the spectrum.  And what’s more is that neither party knows the other’s figure.  You know only that you need more than $10K and client knows only that it needs less than $100K.

As the website provider, you want the project to take as long as possible.  It needs to go sailing past $10K, and hopefully as close to client’s upper bound as possible.  The less efficiently you work — the more hours it takes to build the site — the better your financial outlook.

Read More

By

From Developer to Consultant

Editorial Note: Next week, I’m going to Panama to explore the canal.  I have no idea how much internet access I will see, so next week could potentially be a quiet week for DaedTech posting, if I can’t log in to publish a few cross posts.

If you write software, but not for the company that signs your paychecks, this title may sound strange to you.  “What do you mean, ‘from developer to consultant,’ when you can be both?”  I have answered that question previously, so I won’t rehash it here.  Suffice it to say writing code for someone other than your employer does not a consultant make.  (But read that post, seriously, because it becomes even more important later in this one.)

A few readers have submitted variants of the same question, so I’ll capture it simply, and as a composite.

As an independent, how do I go from doing app dev work to consulting?

I added the bit about independent status because it matters.  Without that, I could answer trivially by saying, “get hired by a consulting firm that wants you to consult, and let them train you.”  But if you go from contract to contract slinging code or if you write code as a W2 employee, you have a less obvious transition.

The Nature of Both Beasts

Before I lay out a tactical set of steps, I need to define the underlying nature of both roles.  In the taxonomy post, I approached the matter in terms of definitions, as one might expect from a taxonomy.  Here, I want to talk philosophy.

I once gave seeking app dev work a satirical treatment.  I asked the reader to imagine a world where, instead of “I’ll fix your garage door” contractors advertised their services with “I have 5 years of hammer, 2 years of table saw, proficiency with 6 kinds of metal, etc.”  As an app dev contractor or W2 employee, you offer the world the latter.  You say, “here’s a brain dump of stuff I’ve done, so all I need is someone who knows how to make me useful and who also signs checks, and we can get going.”  You offer exactly the sum of your experience tuples.

SwankyToolBelt

A consultant, on the other hand, offers services akin to general contractors.  “Call me if you have a problem with your garage door, and let me worry about finding someone who can do the job and how many ‘years of hammer’ they need.”  An app dev free agent solves one problem (writes code for someone who can’t) even as he presents another (figure out what skills are needed and manage that person during execution).  A consultant steers clear of execution and offers only guidance.

Read More

By

How to Get an Edge As a Consultant

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the documentation around code metrics and queries.

I’ve made no secret of, and even frequently referred to my consulting practice, including aspects of IT management consulting.  In short, one of my key offerings is to help strategic decision makers (CIOs/CTOs, dev managers, etc) make tough or non-obvious calls about their applications and codebases.  Can we migrate this easily to a new technology, or should we start over?  Are we heading in the right direction with the new code that we’re writing?  We’d like to start getting our codebase under test, but we’re not sure how (un) testable the code is — can you advise?

This is a fairly niche position that’s fairly high on the organizational trust ladder, so it’s good work to be had.  Because of that, I recently got a question along the lines of, “how do you get that sort of work and then succeed with it?”  In thinking about the answer, I realized it would make a good blog post, specifically for the NDepend blog.  I think of this work as true consulting, and NDepend is invaluable to me as I do it.

Before I tell you about how this works for me in detail, let me paint a picture of what I think of as a market differentiator for my specific services.  I’ll do this by offering a tale of two different consulting pitfalls that people seem to fall into if tasked with the sorts of high-trust, advisory consulting engagements.

LikeABoss

Read More

By

Static Analysis for Small Business

Editorial note: I originally wrote this post for the NDepend blog.  Check out the original, here, at their site.  While you’re there, download a trial of NDepend and give it a spin.  It’s one of the most important tools in my software consultant’s tool chest.

I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business.  I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.”  But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.

And, since that is a perfectly reasonable question, I bit my tongue against the snark.  I gave a short answer more or less of “yes,” but it got me thinking in longer form.  And today’s post is the result of that thinking.

I’d like to take you through some differences between small and large organizations.  And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.

Read More

By

My Realizations about Software Consulting

I consume a lot of audio books.  Most recently, this habit led me to listen to a book by Allen Weiss, called Million Dollar Consulting.  The title yields the book’s premise in deceptively simple fashion: a guide to building a seven-figure-per-year solo consulting practice.  Sound crazy?  Two and a half years ago, when I went into business for myself full time, I would have thought so.  Now, it sounds pretty doable to me, if that’s your thing.

BigPileOfMoney

This isn’t to say that have a million plus dollar per year consulting practice — just that I understand how someone could achieve what he’s talking about in a way that I couldn’t have back then.  Listening to this book gave me cause to reflect on my free agent journey, so I thought I’d write about that today.  (I know there are some who’ve wanted more of these posts anyway)

When I first took the free agent plunge, I had a fairly vivid picture of how it would work.  I was leaving a job running an IT department, and what I sought was a practice where I helped solve targeted technical problems for a portfolio of clients, rather than solving all sorts of organizational problems for a single entity.  I wanted both to diversify and to become more project-focused.

The Neophyte Techie Free Agent

Beyond that, I didn’t really have a firm grasp of the path to growing profit.  At the time, I assumed that technical consultants did what members of app dev groups did, but for much higher pay (due to transience and achieving better results).  That is, I might do a mixture of application development, architectural consulting, training, mentoring, troubleshooting, etc.

I’d start out charging, say, $100 per hour and then let supply and demand drive up my rates as I pleased more and more clients.  This, I reasoned, was the path to bill rates exceeding $250 per hour.  And, why not?  That seems to be how so-called app dev consultancies work, offering blended rates and billing out their principals and super-awesome-folks at $250/hour.

At the time, I remember chatting with John Sonmez of Simple Programmer.  He and I knew each other through the blogging community and through Pluralsight.  He’d made a similar career play a year or two earlier than I had, so I picked his brain about his journey.  He told me something quite memorable, in that it proved prescient, but was inconceivable to me at the time.  “I want to get away from trading hours for dollars.”  Huh.

Read More