Great sample website contract http://stuffandnonsense.co.uk/content/dl/2010/05/11/contract-killer-2nd-hit.txt
Shorter Deliverables are Better
It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.
Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.
Cost of the Solution
There’s the known cost in terms of what we’d spend to solve a problem. That’s the cost of solution. But we do better comparing it to the cost of the problem to get an idea of whether we actually want to invest in the solution. Sometimes the solution costs more than the problem. That’s a pill perfectionists swallow, a lot. So when we face a recurring manual task we may first calculate how much that task, the problem, costs us. And then we look at how much automating the task, the solution, would cost. A task that requires two minutes every week may not be worth spending several tens of thousands of dollars to automate.
And then there’s cost in terms of comparative cost. Personally, I’ve found myself saying “we shouldn’t do this because it’s expensive” a lot. That “expensive” has rarely meant high-priced. It had to be seen as comparative, “more expensive.” In a code scenario let’s think of solving a styling problem by inserting extra markup instead of accepting additional complexity in the style sheet (although you already know that getting the markup right is important). That solution could turn out expensive not absolutely, as inserting that extra markup might only require a few seconds, but relatively because it would require every team member to know about the new constraint, because it would require being done many more times, and because overall it would be more work.
Thoughts on being a programmer
- Don't be an asshole.
- Simple code is hard to write.
- Exquisitely simple code is exquisitely hard to write.
- Just because it's easy to understand doesn't mean it was easy to write.
- In fact, the easier it is to understand, the harder it probably was to write.
- There are many ways to do something.
- The first way you think of is highly unlikely to be the best way.
- Anyway, there probably is no best way - just lots of ways that are differently good.
- There's always plenty of room for improvement - in your code, in your abilities, in you.
- If you think you're as good as you're ever going to be - you're probably right.
- "One-line changes" aren't.
- Learn to desire success more than you fear failure.
- You're only old when you can no longer learn new tricks.
- Always back up before tidying up.
- Err vicariously.
Sometimesit's OK to be a bit of an asshole. But don't make a habit of it.