Things Web Developers can learn from craftsmen part 1Saturday, December 31st, 2005 at 10:37 am
I spent Christmas at my parents’ and went through some of the old paperwork to see what can be ditched. One of the contracts I found dated 1996 and was my application to start a web design business.
I remember clearly that back then the government agency dealing with new businesses asking me if “web design” is a craft, and if what I am doing is weaving nets in a beautiful manner. While that left me speechless back then I realize now that there is a lot craftsmen and old trades can teach us as web developers.
I jobbed a lot as a bricklayer, painter and plumber amongst other things and learnt one thing pretty soon:
Although you think you are dead clever and the people you have to work with might not be your cup of tea when it comes to enlightenment about equality or politics – in their area of expertise you can learn a lot from them and you know less than they do. A lot of times higher school education leaves us with a lot of knowledge, but not much practical thinking. Simply by listening you can prevent making an idiot out of yourself or work hard without getting the job done.
Here are some things craftsmen do that we should write on our flags as well:
- Using the right tools for the job
- Not committing ourselves to the unknown
- Communicating the amount of work clearly
Use the proper, high quality tool for the job
Imagine the following conversation:
“Acme Plumbing Limited, how can I help you?”
“I have a leaking pipe somewhere, could you come and fix it?”
“Sure we can, provided we can find the problem and bring the right tools and spare parts.”
“No problem, I have all the gear here, all I need is you fixing it, how much does that cost and how long will it take you?”
“Well, I cannot commit myself without taking a look at the problem.”
“Yes, I understand that, but I need to know how much it costs and how long it will take you.”
“Again, this depends on your problem.”
“I thought you are an expert. Well, never mind, can you please come around now?”
[… one ride later…]
“Here is the pipe, somewhere there is a leak. My nephew had a go at it earlier and may have bent some of the pipes and worn out the screws. I got this scotch tape and a rock with a blunt end. I also have a screwdriver that is not really straight. I just leave you to it, please don’t take too long! Shall we say an hour?”
It is somewhat unlikely that this plumber will take on the job – he is more likely to charge the ride to the client and leave, muttering some short and precise, albeit derogatory words on the way. Web Developers, on the other hand, might have heard something like:
“We want you to design our web site. We’ve done it in 1998 with a program that you guys know probably – CoolWebSiteMagicWizard95+. We want it to be really nice and we need some Flash, DHTML, AJAX and XML! It would also be cool to be able to edit the page ourselves. However, we lost the paperwork of the company that puts our site on the web and we don’t want to spend any money or change any of that. It would also be very good to make our own images – we have a digital camera and that one came with a good photo edit thingy.”
You don’t always have the choice to say no to something like that – especially when you are a freelancer at the beginning of your career. However, in the long run you will not be able to support any bigger clients when you tie yourself to a lot of low-budget, high maintenance clients.
Personally, I don’t see any point in hard coded HTML navigation and page state any longer. You’ll have a hard time finding any server these days that does not at least support PHP or SSI. LAMP (Linux, Apache, MySQL, PHP) based servers are a dime a dozen and even if you only use PHP for includes you make your life so much easier.
Don’t commit yourself to the unknown
If you call a garage and tell them your car “sounds funny” you are not likely to get a pricing proposal – they’ll want to take a look at the car first (and practice the well known muttering of “oh my god” and “shoddy” accompanied by a headshake).
The same should happen for us web developers. There is no such thing as a “5 page web site”. Sooner or later the client will want to expand the site and change the navigation – it is a lot easier to plan for this contingency and explain the extra work to the client than to develop something that is in a fixed state and will be hard to change later on.
Redesign of existing web products is generally a lot harder and more time-consuming than starting from scratch – all the more annoying that we don’t have that as an option a lot of times these days. If we plan our sites scalable and leave spaces in designs for more content and more navigation items we won’t have to explain a new look and feel to the client at a later stage. On the other hand it is very easy to totally redesign a site in the future – if we properly separated content and presentation.
Communicate the amount of work clearly
Garage owners will give you a fixed amount of work hours on your car repair that you have to agree on before they even touch your car. If they find other faults during the repair they will tell you about them and re-agree the extra amount of work. This does not happen a lot in web development.
A lot of times we cut our own budgets – either to get our foot in the door of a certain client and bargain on follow-up projects or because of wrong assumptions. This is especially the case when the project manager talks to the client without asking the developers for their input.
Developers, on the other hand are sometimes likely to underestimate the amount of work – assuming they can re-use some older code or that the rest of the product will be in a state that can easily fit their bit of work in.
It is much better to properly analyse what is available and what the client expectations are than to simply “go for it”.
This research and client communication hours – before start of development or even visual design – is hard to sell, but it will cut down on the final amount of work hours and overall cost immensely.
If you run into problems whilst developing, make sure to flag these and their impact on work load to the PM (or the client if you have no PM) immediately – it simply makes no sense to work for free to cover up your own mistakes.
To be continued…