2008-11-15 minus 2008-10-01 can’t be one if you’re calculating rent. It must be 1.466…

Note: end date is not inclusive.

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.

1. How to Use Design Patterns
2. Erich Gamma on Flexibility and Reuse
3. Design Principles from Design Patterns
4. Patterns and Practice
5. Eclipse’s Culture of Shipping

At the end of the fifth part the author promises next one to come on July 11th but I failed to find any.

Question

How do you work with design patterns? Do you go back to your favourite book and refresh your memory from time to time? Do you work up your own patterns? When you have a situation you need to solve do you go googling to see if there already is a pattern for it?

That’s how I found design patterns and Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (ISBN: 0201633612, Addison-Wesley Professional).

Surprisingly enough it wasn’t and is not going to be translated by major Czech publisher of computer related literature Grada. Costs for getting it from Amazon.com are discouraging so what now. (see Update below)

Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts (ISBN: 0201485672, Addison-Wesley Professional).

This book was excellently translated by Vladimír Lahoda as Refaktoring: Zlepšení existujícího kódu (ISBN: 80-247-0299-1, Grada Publishing a.s.) so I was able to get it from a local library for free. Refactoring in general may not be always related to what I set out to look for however, this book is full of design patterns indeed.

You learn here how to proceed when you want to change your code without changing the program’s behaviour. You actually get a cook book of common design problems and step-by-step instructions how to solve them. Please note that it’s about design – not implementation or performance problems.

Here’s what I think this books brings apart from what’s its obvious goal.

Code Smells Hints

Because it lists problematic code and solutions to it you get to learn what a problematic code is and why.

You learn OOP as you read it

My blog is meant to be about PHP and this book uses Java for its examples. I don’t think it matters. The OOP principles behind it are the same.

Gives you arguments

If you ever had to lead a team you know what it means to know the right way but to miss the arguments to support your point of view. You know it but you’re unable to convince the rest of the team. Now you can use parts of the book.

Question 1

Do you rewrite your code to make it easier to read? Or do you do your best when you write it at the first time and when you need to add more features you just try to hack it as nicely as possible? What are your criteria for a project that is worth refactoring?

Question 2

How do you deal with refactoring from the project management point of view? If you are the boss then how do you promote refactoring – or how do you keep it within reasonable bounds? If you are the programmer then how do you persuade your boss that refactoring is crucial for your application in the long run? Maybe you don’t tell him at all and steal time for it like Robin Hood :-)

Update:
I just learnt that Czech translation of Design Patterns exists: Návrh programů pomocí vzorů (ISBN: 80-247-0302-5, GRADA Publishing a.s.). It is sold out though, and Grada doesn’t plan any reprints.

I’m working on a post about a book I read (Refactoring: Improving the Design of Existing Code) so subscribe to my RSS feed to get it fresh.

I plan to end all of my posts with a set of questions to stir up the conversation and to guide your comments to topics that I’m insterested in. Read further to see what I come up with to start.

Question 1

As far as I know OOP encourages programmers to use a lot of small-task classes and methods as opposed to a little of big-task methods/functions. I understand the advantages but how do you ensure that all methods and their purpose is known to all programmers so that they actually use them instead of writting their own again?
Do you print a diagram of the whole system each month and post it on the office wall?

Question 2

The only projects I deal with are web pages or intranet/extranet applications. For a simple booking script would you still use OOP or would you not mind using well structured linear programming? By well structured I mean a library with shared functions, associative arrays with definitions, constants for types etc. If you would intentionally use OOP (that means not just because you are used to it) then why?

Well, thanks in advance for your comments. Hopefully we all will benefit.