Delivery delays, changes in specification that should have been known beforehand, bad and outdated documentation, team-mates who cause more damage than good.
These things (among many others) make programming difficult to like.
The ol’ good way is to think first, then do the job, deploy it and go have a break. The first paragraph describes what you get if you still believe in the old good way.
Extreme Programming Explained: Embrace Change by Kent Beck, ISBN: 0201616416, Addison-Wesley Professional (Czech translation: Extrémní programování, ISBN: 80-247-0300-9, Grada Publishing a.s.)
Reading this book may help you to change your world view – at least from the programming point. There always will be a change so why won’t you accept it and do everything possible to cut its cost. Not having experience with XP as such I cannot advocate for adopting it totally. However, reading the book did change me:
- I no longer think that I can predict changes
- I organize projects into phases, deploy as soon as possible and add functionality incrementally
- I don’t blame users for not being able to give me good specs until they get their hands on the finished software (it’s like blaming rain for being wet)
- I write my code so that a kid can understand it (i.e. me after two months)
- I don’t worry about rewriting half of my application next week – I take it into account when giving quotation in the first place (multiply it by two)
- When I get specs (the first version) I’m not surprised that they’re worthless. Hey, it’s just something to start with. Just don’t forget to take it into account when giving quotation. (again: * 2)
- Speaking about quotations: I write the specs not the customer. The customer sends me his ideas (he calls it specs, of course), I rewrite it into specs and have it confirmed. Repeat {} until (confirmed == true); Then I give the price.
- I know that never-ending projects are ok. There’s no “we’re done let’s go home”. Plan your time so that you still have some after the project’s deployed. (That’s not the deadline, mind you.)
Now that you know how clever I am – go get the book from local library and be that way too :-)
Question 1
Have you ever tried programming in a pair? What transition were you going through after you started doing so? Did you like it right from the beginning? Are you glad you returned to working alone?
Question 2
Do you think programming in a pair can work over Skype + shared desktop? A webcam comes handy? Any experience?
Question 3
Do you know of any literature on how to give quotations? Let’s face it – it’s a major part of our work and a bad quotation can turn a project into hell.