I am currently in Prague, Czech Republic and gave a talk on re-use, professionalism and ease of development at the WebExpo.
Today I am going to have a longer chat with the people at the University about accessibility and creating a WAI-ARIA enabled framework for web applications.
For now, here are the slides of the WebExpo presentation and the audio recording of the talk. There was a video streaming, too, and it is up to Microsoft now to get this out as a recording.
Slides
Audio recording
You can download on being cleverly lazy as an MP3 - 36MB or see other audio options on archive.org
Notes / Transcript
Today I will talk about the fact that being cleverly lazy will make you a better developer.
First of all, I am Chris, a developer evangelist. This means I am a developer who evolved into a role where I can tell other developers how to have an easier life and tell my company what other things developers would want to make it even easier for them. I’ve written a developer evangelism handbook if you are interested in learning more about this role and why your company would benefit from having someone like me.
Cleverly lazy
Let me quickly define cleverly lazy here. Lazy is “I don’t want to do it” wheres cleverly lazy is “I don’t want to do that ever again so I do it right this time”. In development the difference between lazy and cleverly lazy is that lazy products do the job but are impossible to maintain whereas cleverly lazy products do the job, are easy to understand, extend and are built on a solid base.
Evolving the web
Our job as developers, designers, planners and organisers of web products is to evolve the web. We should have the chance to concentrate on building solutions that make people happy to use them rather than having to work out how one browser or another fails or how we convert data into a format the web technologies can display and understand.
In order to achieve this, we need to be free to do new things rather than worrying about the past.
The feature loop trap.
One problem is that as developers, we stand in our own way. The biggest trap that there is for developers is the feature loop:
- As developers we love to take a complex problem and tackle it. We love solving problems, that is why we become developers.
- We then normally and quite quickly find a simple solution to the complex problem.
- We then release the solution to the world and get feedback.
- This is where it goes pear-shaped. We get stuck in a feature adding and feedback loop until the elegant, easy and simple solution becomes a complex one again.
- Other developers will find our former simple solution and will think “hey, this is a complex problem, let’s make that easy!”
This keeps us from evolving as web developers. We don’t develop the web, we fill it up with solutions to the same problem.
My solution
The next issue is that as developers we love to find solutions ourselves and not use other people’s information. We appreciate other people’s work but in the end we only trust ourselves to come up with the best solution ever.
Short attention span
The problem with finding and building own solutions is that we tend to lose interest in them really fast and then leave them behind as we already another complex problem to simplify. This leads to lots of half-finished solutions on the web that don’t get any love any longer.
Unmaintained code is a security problem
All the code that is not getting any love stays unmaintained on the web and becomes a wonderful attack vector for new security threats or vulnerability exploits. Nothing beats being up-to-date when you want to build secure systems.
Things web developers must know to do their job.
Looking at our job as web developers, here are the things you have to be aware of to build things that people can use.
- The technologies involved
- How browsers deal with these technologies and how they fail to support them
- Security concerns and attack vectors
- Usability and accessibility of the product
- Internationalisation of our products
- Performance concerns
- Multiple platform support
- Flexibility of the interface
Browsers suck
Browsers are the bane of our existence as they are unpredictable, unreliable, there are hundreds of them (in various configurations) and they are not being updated by people out there.
That is a lot to know and deal with. The good news is that you don’t need to know all of it.
Good developers are like librarians
Librarians are great people. Instead of knowing everything that is in the library they know exactly where to find the information to solve a problem. As a cleverly lazy developer you should do the same.
Build on a solid foundation
Web development libraries came around for one simple purpose: Make our life as developers easier and our work as web developers predictable. They make browsers suck less and work around differences in browsers. They allow us to use web standards and get results instead of bugs to fix.
Build with components
If you build web applications and interfaces take a look around for what has already been created for you. Almost every library comes with widgets that are tested, work for everybody regardless of ability and can be changed to your needs. If you build your own component you are very likely indeed to forget some very necessary functionality that a collaborative product already had put in.
Use a good debugging environment
You can’t write great products without being able to know what is going on. Luckily enough nowadays we have great debugging tools like Firebug, Yahoo Profiler, JSLint and validators of all kind.
Plan for extensions
If you build a solution, plan a way so that people can extend it without having to change the central code. The central code should only have to change when there is a new browser or platform to be supported or there’s a security fix. Other than that people should be allowed to extend by listening for events or using other API hooks into your product.
Read, use and write documentation
If you build something, document it. There is no such thing as code that explains itself, that is a myth and an arrogant one at that.
Use the web
One of the really cleverly lazy things to do these days is to use the web to build your product rather than building your product and putting it on the web. Distribute your content on specialised systems like Flickr, YouTube, Delicious and LinkedIn and then put it together in a centralised CMS. That way your site will be easy to maintain and not vulnerable to a single point of failure.
Use APIs
To achieve this you need to use APIs. APIs can take a lot of your time to read up on and understand which is why it is a good plan to use YQL as an in-between to avoid going crazy on authentication and understanding what parameters go in and what data comes out.
An example
As an example, let’s take a look at a web site built solely from data on the web, using YQL and PHP.
Thanks!
Thank you, remember if you use what is out there you have time to be creative. I want us to write code most of our time, not to fix bugs.
