Thoughts from a Thirsty Bear

Just spotted in a job ad for a lead developer: "You will be expected to implement a rigorous Agile Development process and work with the Technical Architect who will define the technologies and toolsets"

Finally, after several days of thinking, searching for templates, scratching head over the CMS and rewording, my poor, neglected website has been revamped. Or at least Stage 1 is complete, and it is now in a state where I can iterate further changes over the weeks/months/years. It now reflects more accurately what I actually do these days, which is an added bonus!

Ron Jeffries has just blogged about dropping quality in favour of speed. Take a look at Quality-Speed Tradeoff — You’re kidding yourself . Having seen many, many projects fail because of this common fallacy, it is a subject close to my heart (but there goes the draft blog article I was writing....). In summary, there are two choices. Subjective historical addenda are mine based on my experience: Reduce quality to go faster. You might get ahead short term, and you might even get ahead longer term if you don't add too many bugs and if you don't make the code uninhabitable. [But history is really not on your side here.] Increase quality to go faster. There is a chance that you will over-polish and not add important business functionality. [Historically this will not happen. Especially if you make this possibility an integral part of the quality process by holding regular customer product reviews and focus on delivering important business value first.]

It would seem that someone at that fine institution Google had a bit of finger trouble over the weekend. I can't help thinking that some (more?) unit testing might save them a whole world of pain and panic in the future. 'nuff said.