Wednesday, March 6, 2013

20 Rules of Software Consulting

I'm going to be gradually republishing some of my older content from my prior blogs here so that people can find it again.  I'll also be updating the stuff which needs updating, of course.   Here's a revised and updated favorite: the "rules of software consulting".

  1. Technology Reflects the Business: show me a client with a chronic software problem, and I'll show you a client with a chronic management problem.
  2. Three Things You Will Never See:
    a. A timeline which is too generous;
    b. A client who pays too quickly;
    c. An accurate and complete specification.
  3. Half of Applications Are Immortal: "temporary, one-off" applications often last for years, and there is code from the 1960's which is still running today. Always plan for longevity.
  4. Bad Clients Will Destroy Your Business: half of your success will be built on the ability of recognizing bad clients and avoiding them or terminating their contracts before they suck away all of your time and resources. Always be able to walk away, even if it means giving a refund.
  5. Ask Not What's Possible: the question is not what you can do, the question is how much the client is willing to pay for it and how long they will wait.
  6. Time Substitutes for Money on a Logarithmic Scale: e.g cutting the time by 20% will require doubling the budget. Cutting the budget by 30% will quadruple the amount of time.
  7. All Estimates are Optimistic: new application development will take three times as long as you expect, and cost twice as much. Or vice-versa.
  8. Three Things You Will Never Have Enough Time For:
    a) The specification and prototypes
    b) Documentation
    c) Code maintainability
  9. All Substantial Applications Have Platypuses, which are objects or bits of data which defy all attempts to fit them to well-defined business processes. Platypuses are both why perfect data integrity is unachievable, and the source of at least 30% of troubleshooting.
  10. Don't Call it Refactoring:  clients never pay for cleanup, even if that's what they need.  Figure out a way to call the refactoring something else so you can get it done.
  11. The Longer You Wait to Refactor, the Longer It Will Take. Major template or schema changes at production time are particularly deadly.
  12. Always Have a Contract, even for one-day jobs. Also, use your own contract, and not the client's, and have your contract written by a real attorney. It's worth it.
  13. The Contract-Writing Process Is a Litmus Test for Its Fulfillment. If the client spends a lot of time arguing over the contract, then actually working with them (or getting paid) will be even more difficult. If the client insists on an odd and obscure clause, they're planning to exercise it.
  14. The Client Has Very Poor Memory: no matter what they sign, the client will have forgotten what they agreed to within days, if not hours. Document all requests and changes and keep copies.
  15. Never Agree to a Fixed Bid for anything where you have not done the same exact task at least twice before.
  16. Third Parties are Incompetent: never agree to a fixed bid or success-based payment for any task which is even partially dependent on the speed, documentation or product quality of a third party not under your direct control. This means no fixed bids for data interchange or fixing other people's code, ever.
  17. The Client has No Taste: never allow the client to choose your tools, your subcontractors or your work environment. Or at least charge them a lot extra for the privilege.
  18. Always Bill for Meetings, or you will spend half your life attending them.
  19. A Half-Empty Mailbox Is The Exception: usually, if one client decides to pay unusually late in a month, all of your clients will. Always be able to survive 60 days on your savings.
  20. A Sufficiently Late Project Will Never Be Completed.  In general, any project which is more than 150% past its original deadline has sufficient systemic issues to permanently prevent delivery.


  1. Thanks for the nice write-up. Though I agree with most of it, I couldn't accept the point 8-C "Never be too concerned with code maintainability". When you say, plan for "longevity", then you kind of contradict your statements.

    When you are consultant, I believe, more than the customer you should set your own quality of standards and definitely, writing a well readable and maintainable code must be a part of it.

    Thanks again.

    1. Vijay,

      That's a linguistic issue. "You can't be ... too concerned about code maintainability" means: "It's not possible for you to have too much concern about code maintainabilty. Any you have is not quite enough."

  2. time to treat management like I'm a consultant... and sneak refactoring into feature requests...

    1. Caleb: "New feature X requires the job scheduler, and in order to add new jobs to the scheduler I'm going to have to fix the API. Hence the 22 hour estimate on Feature X"

  3. Good rules, make a lot of sense. I would add one more:
    21. Do not write previous 20 rules with white font on red background - 1980s with EGA display are flashing back :-)

    1. Paul,

      Yeah, I've gotten a lot of feedback on the theme. I'll be changing it as soon as I have time to play with layouts.

  4. I'd shorten #15 and #16 to just "Never Agree to a Fixed Bid for anything".

    1. Actually, you can increase your margins with fixed bids on tasks you know very, very well. For one thing, fixed bids mean that it makes finanical sense to develop internal tools which make the task faster, which hourly billing doesn't. Also, we have tasks where we bill the equivalent of 10 hours for work which takes us 6 to 12 hours, median 8. That means we've increased our average profit margin by 2 hours. So a fixed bid where you can predict, with a high level of confidence, how long the task is going to take you can be a revenue enhancer.

  5. I'd add another to the list -- "Bringing on freelancers to desperately attempt to meet deadlines will bleed every dollar of profit from the project."

    1. Well, that's pure Mythical Man-Month: "Wanna make a late project even later? Add people to it!"

  6. This comment has been removed by the author.