On Monday night I went up the Square Pig in Holborn (where the above subtle We Love branding was spotted) for the monthly London Web Standards meetup. This is a great night of geek talks and networking, focussed mainly on front end development, and a beer or two afterwards.
The two speakers this time, Marcus Alexander of EMC Consulting and Arran Ross-Patterson, both had something to say on the conflict between the web standards approach most of us advocate and the actual reality of doing client work where deadlines and scopes and budgets are in constant flux.
That is not to say that either of them were recommending throwing best practice to the wind and just hacking out bad code to get sites out the door – but there was an acknowledgement of the intrusion of the real world on a developer’s peace of mind, a few useful coping strategies and most definitely some familiar client situations.
Marcus started out by explaining that what seems at first like a poor design can often be there for a reason, citing a new block of flats near his house where an ugly, oddly shaped roof turned out to be an effective shield from the effects of the next-door fried chicken outlet’s extractor fan pipe. This of course has a parallel in web development, where he explained that the best solution is the one that meets the requirements – not necessarily the most elegant code.
This then creates a potential sticking point. What are the requirements? If the answer is “It must be out by Christmas” then you probably have a bit of room to negotiate on scope but it’s not really a clue to what the client actually wants.
Just as important is knowing who you are delivering to and a few simple questions such as what the hosting environment is, folder structure or naming conventions, use of code libraries and required browser support. If there is a form to submit, where does it go? These might seem obvious when written down, but the number of projects I’ve come into throughout my career where even these things are not known doesn’t bear thinking about.
Once you think you know the answers to these questions, he said, get them agreed. They’ll probably change, but at least you have something to refer back to.
Past this point the onus is on you as a developer or team leader to do things in a way that makes your life, and your client deliveries, easier. Defined coding standards can be a great a great idea, but if you’re making the decisions you need to be able to justify them. A long, dry document is unlikely to be read so a one-pager with code examples is a much more useful asset. If you’re following someone else’s standards, and you don’t like them, but they’re well justified, put up with it.
As a team lead it’s vital to have an overview of what plugins and code libraries are being used. Regular code reviews help you keep on top of this. When clever line of jQuery in your main Javascript file is the tip of a 70kb plugin iceberg that you had to re-engineer to do something it didn’t handle in the first place, it might be the right time to reconsider your approach.
Even in a project where you are only delivering front end (HTML, CSS, Javascript) a build process can prevent headaches and automate things like version numbers and code minification. Apache ANT is a great utility for these, even if the instructions require several PhDs to decode.
Good coding standards and engineering practices should also minimise the amount of bugs that crop up. Actually, forget that. They won’t. But Marcus suggested that a hundred bugs on the average site is not a scary number. Once you look into the details you’ll probably find that many are duplicates, some are mis-reported and of those that are actually code bugs there is probably an even split between known issues and requirements that no one wrote down.
Meanwhile Arran’s approach was that if every line of your HTML doesn’t validate it’s not a disaster, as long as you can justify what you’re doing. A great example was the valid and semantic markup around a definition list, where there is no obvious way to link a term and definition together except by their implicit ordering. Unless you illegally nest one inside the other, and then it gets a lot easier. Tables are often used to mark up a calendar month in a date picker, because the common grid view looks like a table. But a month’s worth of days is actually an ordered list. So what is the best solution? Dare I say it’s the one that meet the requirements?
As you would probably expect from a gathering of standardistas there was some heated debate in the room. The main concern was whether passing over validation to suit the requirements of a project is a betrayal of all the hard work that has been done to get the standards formulated, accepted and adopted in the first place. Well yes, it kind of is, but as they said at the start this was not advocating tearing everything up but using the best technique to get the right result. If a line of invalid markup might cause display issues in a future release of a browser, but it solves a problem in a campaign site that might only be online for three months, you can probably get away with it.
An interesting suggestion from the floor was the idea that developers could collaborate to standardise semantic patterns across the web. This would help with understanding and moving forward best practices, and also the work of data scraping services where dozens of different patterns can be found in the presentation of similar information across sites, for example in e-commerce.
So definitely an interesting evening. As a developer my first instinct is to make something that is as well coded as it can be. As a team lead my concern is the sanity of my team and their effective collaboration, both within their discipline and with others. And as someone making key communications with our clients I have to give equal weight to their requirements and the quality of work we deliver to them.
By the way, if these are the kind of conundrums and challenges you love to deal with on a daily basis, why not check out our open role for a creative developer?
