exactly :D Kind regards, Keri Henare --------------------------------------------------- [e] [email protected] [w] kerihenare.com [m] (+64) 021 874 552
PLEASE NOTE: I check my email 3 times per day and will respond at these intervals. For anything urgent please ring me. --------------------------------------------------- On 18/03/2010, at 1:19 AM, Richard Clark wrote: > So, I was going to respond to this conversation earlier, but something > didn't really feel right about the way it was all going so I left it. > > Aaron, Harvey and others present a compelling argument. We know that > every project is constrained by a limited set of resources, and it is > the ability to juggle those resources to match business needs that is > part of what makes a good professional programmer. In this way, > arguments about limited ROI and simply having more important things to > do dominate the discussion and lead to people thinking HTML validation > is a nice-to-have that doesn't really matter. > > What finally popped up in my mind - inconveniently moments before I > was going to bed, as usual - was that we're simply aiming too low. > > "We are what we repeatedly do. Excellence, then, is not an act, but a habit." > > The risk we run, when we regularly aim for merely Good, is that we > become someone who cannot ever deliver Great. This applies to > everything, not just HTML validation or even programming. A > fundamental aspect of greatness is attention to detail. The difference > between the house designed by a good architect, and the one done by a > great architect, is not in the size or the shape or how pretty it > looks. It's in the myriad of different tiny ways it helps the people > who live in it achieve their goals. > > For a web application, HTML validation is part of that. Precise, well > formed HTML is easier to maintain, easier to debug and easier to use > for numerous situations from screen readers to screen scrapers. Every > app should have perfect HTML validation as a goal. It should almost > never be the highest priority (maybe if you're doing w3c.org or > something), but it should be there in the task list because without > it, and without comprehensive unit tests and lint checking and code > documentation and every other little element, it can never be great. > > The real world imposes limits on us, a number of these tasks, and > others, may never be realised in a given project, but if you start day > one of the project saying "Reality sucks, lets aim low" then you've > already sold yourself - and your client - short. You'll never deliver > a great project that way. > > The next time you start a project, don't compromise on the vision and > don't forget the little details. Make sure you put the priorities > where they should be - this is not an excuse to mess up delivering the > value the business needs - but add the tasks in anyway, even if > they're at the bottom of the list. > > Every project you do should be your best project yet. Every project > you do should exceed your own expectations. When you put these tasks > in your task list you are saying "I'll get there, I'm so good at this > that I will get to the point where nothing would make this project > better than having 100% valid HTML everywhere". > > The world will never have enough great programmers. We need you. Don't > sell yourself short. > > Regards, > Richard. > > -- > NZ PHP Users Group: http://groups.google.com/group/nzphpug > To post, send email to [email protected] > To unsubscribe, send email to > [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
