Along with the growth of my consciousness and experiences in software development, I discovered that there are three words which can be used universally really count: early, often and thoroughly. Here are two examples of using the template:
Refactor early, refactor often, refactor thoroughly.
Test early, test often, test thoroughly.
For 9-5 programmers (The programmers who come to work at 9am, shut down their computers at 5pm and go home with coding-proof bubbles around them.), my points would seem to be over killing. The overwhelming effort needed to practice the principles is enormous, after all, not every coder would like to put these things as his/her epitaph.
For well versed desktop application developers, these three words, early, often and thorough, might not be innovative, as we all have read The Pragmatic programmer and Steve McConnell’s Code Complete. However, from a web developer’s point of view, they are quite interesting.
A typical web application development circle includes requirement, specification (optional), design, coding, testing and delivery. We apply different three word formulas to each stage.
Requirements and Specification
Gather early, gather often, gather thoroughly.
Clients, especially shareholders, usually are non tech savvy type of people, they come to you: ‘We want a website, we want it next month and we like Facebook pop-up bubbles!’. I am so glad you said ‘pop-up bubbles’!
Gathering requirements should be absolutely essential and it is the first deference of disappointment. Some small agencies, including the ones I worked with, tend to pitch their ‘free designs’ in the first meeting, do the hard sells, tell the client nothing could not be done – even if the client want the web to trap real fish.
Instead of trapping clients with free design and ocean deep low price and then rip them off when it comes to tiny changes and maintenance, a well composed contract that is based on enough requirements would be more appropriate. For web applications, personally I don’t think specifications are usually necessary and somehow they produce more disappointment than satisfactions. Reason? it’s not easy to get the specific level right. How specific is specific enough? ‘Membership management’ equals nothing when it comes to design and coding, but ‘The site needs three roles, respectively gusts, registered users and vip users’ will guarantee future changes to be incurred. For a requirements-change-everyday application, you might want to spend more time to gather the right requirements to ensure the solidity of design – both visual and coding.
Design and Coding
Refactor early, refactor often, refactor thoroughly
Not to repeat many great talks (PDF) and discussions on this topic, I will only say one point that I found very interesting yet paradoxical. DRY is the first thing I learned from my C++ class and I believed in it for many years. But for web applications, it becomes quite disadvantageous sometimes: If the page only needs to be alive for three days, code generator and wizard are your best bets. Duplication? don’t worry about that, you would not have a chance to modify them before they die out from Google.
Testing and Delivery
Test early, test often, test thoroughly.
User involve early, user involve often, user involve thoroughly.
Test is a big topic and will not be discussed here.
User involving might be a pleasant way to work with, it is definitely the most efficient way of avoiding disappointment and disagreement. Let the end users involve from the beginning to the end. Give them a prototype of interface to play with, ask for feedback after each stage/component. There is a thing called one-mind, but you and your client don’t usually have it. Sometimes user doesn’t know how much effect would be involved for a small change of his mind; sometimes a big change the client is afraid of telling you may only requires one line code change. Communicating with user can synchronize user’s expectation and developers’ decision, reducing the unhappiness caused by the parts which developers put a huge amount of effort in but lives out of user’s expectations and prevent client changing mind like a kid – which is far more efficient than specification and user would appreciate it.
