Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for March, 2009.

Archive for March, 2009

TTMMHTM: Guardian getting enabled by design,interview,open hack day,bash magic,and XSS filters

Wednesday, March 18th, 2009

Things that made me happy this morning:

Open Hack Day London, 9th and 10th of May – signup now open!

Wednesday, March 18th, 2009

Open Hack Day London 2009

And lo and behold, the Open Hack Day returns to London. On the 9th and 10th of May we have space for around 200 hackers to show us what can be done when you let European geeks run wild and feed them with yummy yummy data and APIs to mix and show this data in ways never before imagined.

As we have limited room you have to get a ticket and give us some information about yourself. We want hackers, not campers and the only way to stop the normal 200 tickets gone in 30 seconds is to ask you to show commitment and woo us with your interests.

However, in order to also cater for the non-hackers there are tickets available for people who only want to come to the tech talks in the morning.

See you in May in London!

My new book idea – “Don’t do it again”

Monday, March 16th, 2009

I am a massive fan of Steve Krug’s “a common sense to web usability” book called “Don’t make me think” and want to write a book that fills the same gap for developers.

Right now the books available for developers are very technology centric and make you learn a lot about a certain job but nothing about how your delivery meshes with the rest of the team. This makes developers a needed asset but nothing that people listen to a lot when it comes to architecture or future progression. Those books sell well and make us feel good as we have improved our technical skills. However as human beings and professional employees we need to break out and get access to calling the shots where our expertise is needed. Our own navel-gazing and non-interest in matters outside our remit prevents that.

Over my career as a developer I found that most improvements of products don’t happen because of top-down decisions but because of geeks on the ground putting things in that will make their lives easier in the future changes that will inevitably come. Our work environment changes constantly and the only way to really build products that are good for us and the people we want to reach is by doing things right the first time and not un-do what we’ve done beforehand or tack extras on in a second step.

I want this book to be a helper to read through in a short period of time before starting a new job or project. I don’t want to give truths or examples that are outdated by the time the book is out but instead want to make developers aware of the power that they have if they work smart instead of delivering only what is needed.

Proposed book outline

1) One of your best assets is your laziness

This chapter will talk about being cleverly lazy – working in the right way upfront to make sure your workload will become less and less the longer the product will be under way. It will cover using the right tools, finding the right resources and organizing your time the way you feel most comfortable and become the most effective.

2) Don’t build for yourself but for those taking over from you

This chapter is all about clever developers aiming for making themselves redundant to the process over time. As a clever developer you want to improve and deliver demanding products and not get stuck in doing the same work over and over again and get stuck in maintenance of products you don’t feel enthusiastic about any longer.

3) Clever recycling is the key

One of the biggest obstacles you find as a developer is to fight your urge to deliver everything yourself. This keeps us from improving as a professional group. All of us have a clever idea to contribute but instead of merging them and finding consensus we all take our small idea and blow it up and stick some feathers on it to make it appear as the best thing since sliced bread. This chapter will talk about how using and building on top of existing solutions will make you a better developer and profit your profession as a whole making it easier to earn more money in the future.

4) Build what is needed and keep it modular

As developers we tend to think in finished products, not in smaller, re-usable components. When we develop something we are very much inclined to put in feature after feature and considering edge cases instead of delivering a solid foundation and add edge-case extensions when and if they are needed. The danger with this is that we deliver products over and over again that over-deliver on the feature front but lack the one single feature an implementer needs – the basics are not covered. This chapter will explain how to avoid this.

5) Aim for excellence

One thing that makes us stop progressing is that over time people are so disillusioned about what they can achieve in a professional environment that “making things work” is the main goal. This is terrible and the only way out is to challenge ourselves to deliver the best product out there and aim for excellence. Only if we challenge both ourselves and the people we work with we’ll be able to deliver products that change people’s lives. This includes planning bigger from the beginning. A product that is built with bad accessibility and no internationalization options might as well not be built.

6) Your product is defined by your users

This is a very important chapter for me and overlaps a bit with the feature-fetish of the previous chapter. The main ingredient of a successful product is how it fares with the audience it is intended for. Our users – regardless of ability, location or sophistication are what make and break our products. We need to know who uses our product and how they want it to work. A great example is Twitter. The use of Twitter has changed massively since its conception and its success is largely based in looking at its users and enabling them to do things they want to do.

7) Your biggest challenge is communication

This chapter will deal with how you communicate best with others, how you get seen, heard and listened to in a world as disconnected as IT is right now. Developers are considered the doers, implementers, not the ones with the overall plan. As developers however we feel exactly the other way around and many a time find ourselves saying that if we had had the chance to stop a decision before it happened the product we build would be much better. There is truth to that, but also a lot of prejudice. The right communication is built on consensus and knowing the deliveries of each of the people involved in the product.

8) Your biggest weapon is enthusiasm

The main point about being a good developer is being enthusiastic about what you do. If you build something you have no connection to you won’t be delivering an excellent job – no matter what you do. Enthusiasm is one of the most contagious things on the planet – if you do it right. This chapter gives you ideas and explains ways how I got myself enthusiastic about products even when on first glance they looked like a drag to do.

This is the main idea for the outline. I am planning to write a small book that can be handed over to new developers, heads of department and consulted at the beginning of a new project.

Delivery considerations

I have a few publishers interested and I am thinking about the format right now. One crazy idea I am having – and considering my very full agenda this year is a very good idea is to deliver the chapters as a series of talks and write the chapters as a follow-up after feedback from the audience. These talks could become part of a download package with the book.

What do you think?

TTMMHTM: WWW birthday,Morse Code, Nano puppets, OS design, FireEagle plugin and really getting things done

Friday, March 13th, 2009

Things that made me happy this morning

A few things the web development community can learn from The Green Movie

Thursday, March 12th, 2009

One of the, oh heck, the only really good thing about flying Delta was their Fly-in-Movie competition. This is a section of their entertainment program where they show short movies of budding movie makers who compete to be shown at the Tribeca Film Festival in New York this coming April.

The green film

One of the movies in there is The Green Film and I loved it (“Cold call” was also very good).

The Green Movie

In this 6 minute movie a self-righteous film director proclaims pompously and full of enthusiasm that they are producing the greenest movie ever. All the food is organic, everything gets recycled, all the make-up is free of animal testing and there is not a single thing that is not in the correct order and would cause a frown on the faces of the friends of the earth.

The wrong doers and how they should be lectured

When the main actress arrives she rolls up in a stretch limo and asks for her trailer. The director tells her off for not cycling or using a bus and shows her a deck chair and an umbrella which is to be her “trailer”. He goes on to explain all the bad things that do not happen on his set and especially goes into a detailed sermon over plywood used on other sets and that it actually is based on rainforest wood. He also is very insightful about using the right light bulbs on the whole set.

Getting caught out

The actress on the other hand starts wondering about the professionalism of the whole setup – which culminates in her wondering if the movie is shot on film rather than digital. The director then goes nuts on the mere idea of movies being shot in digital and that digital film is just “TV on big screens”. His rant goes so far as to proclaim that art could never be done with digital cameras. To the arguments of the actress about film processing involving toxic chemicals and shipment of reels all over the world the only thing the director comes up with is “but we recycle – a lot!”.

The movie ends with the actress filming herself in the woods using her mobile (cellphone for Americans).

How this applies to us

This is exactly how we get stuck when advocating best practices on the web. One interesting exchange that shows this is Chromatic Sites advocating for CSS vs. Table layouts and Mike Davies shining a massive big light of truth on the arguments provided.

Another interesting “oh not again” moment was Jeffrey Zeldman doing the inaugural testing of the top 100 sites in a validator causing an avalanche of comments.

You know what? We’re wasting time and energy in these discussions and we are so immersed in our own “doing the right thing” that we forgot to care about what we wanted to achieve in the first place. We get into meticulous details of explaining certain technologies and invent idea after idea based on the same technologies we tried to make people understand by force years and years ago and failed.

Standards and best practices are there for a single reason: make our work predictable and easy to work with other developers. This only works if everybody is on board and understands these best practices – in essence, following them needs to make their job easier. If following a “best practice” doesn’t make our lives easier but produces extra overhead it will not catch on.

Instead of concentrating on showing the benefits of working in a predictable manner we concentrate on ticking all the right boxes and telling everybody who is unfortunate enough to listen about all the details we had to think about to get where we are. We know all about the plywood and the right light bulbs but we forgot to talk in the language of the people we want to reach with our ideas. We are not concentrating on how we deliver the message and that there might be better techniques and technologies available nowadays than the great problem solvers of the past.

Web development is evolving and changing to new channels of distribution and re-use. Widget frameworks allow re-use of the same little application across the web, mobile devices and now even Television sets. These things is what we should have our sights on and not if a certain document passes a dumb validation test or not. Validation is the beginning of a quality control process, not the end of it. Semantic value cannot be validated by a dumb machine but needs a human to check. Zeldman did point this out in his introduction to the test, but this message always gets forgotten in the uproar of indignation over and unencoded ampersand.