As a follow-up to yesterday's blog on billing programming time by hours, I believe I've refined where I was coming from a little bit better.

If your business is where it should be, you should be able to fix price your programming. No matter what. That's should be the rule. You might start a new contract once you're done, and you might very well take some time to amend a current contract, both of which likely happen b/c of customer requests/scope creep once you've start showing what it is you can really do. That's just what happens -- you can only create so vivid a picture in your mind before you see operating code.

How can you do this? By creating great scoping docs in the first place, and it's here (and here only) that you've got your wiggle room. You might charge $X,000 for Y hours of system design consultation, but once you've got a good design, your UI sketched, your data fields mapped, and your functionality set, it's time to estimate hours and come up with a good, fair, fixed price. Then build the app as described for that amount.

Again, some people will be tempted to say, "But every project changes so much during design! If I keep everything set in stone, I'll fall behind simply during the time I'm developing!" Well, if you're in a competitive enough niche, perhaps that's not an exaggeration. More likely you don't have good management practices. And in either event, you don't build in wiggle-room when dealing with software development. What you build-in are processes to deal with change, now matter how small, including times during development where change can naturally occur, and you don't move one programmer from what s/he's doing now until your new specs are every bit as solid as today's.