Tuesday 1 February 2011

A few difficult things in application development

Here are some thoughts I had about developing applications over the last months.

Maintaining documentation

Yeah I know what you think: nobody reads it, waste of time. People just click everywhere and see what it does. This is probably true for most of the geeks, but observing my parents using a computer taught me  you need to document your application features. At least the less obvious ones.

Error reporting

The same way you can judge a restaurant by the look of its toilets, you can judge an application by the way it deals with errors. It's often a taboo subject, but every single customer will use it sooner or later (sooner in general). Give your application a first class feel: Implement error catching/reporting sensibly.

Making stuff contextual

This is an empirical law of application development: Whatever the complexity of the system is, there will always be a client saying 'Nice but if <a potentially always false large predicate)>, then the behaviour should be <something crazy no one will understand in one month time>'. At this point, this is an occasion to:
- Add nasty 'if' statements to the appropriate palces and slowly but surely f***-up your beautiful codebase. The client will be happy.
- Or refactor your application to implement this new stuff in an elegant way. This will take longer. The client will be happy - eventually.

In short: You're doomed.

Moving from single to multiple

Another empirical law of application development: Whatever you think should be unique will eventually need to be multiple. If you think about it, in nature there's no absolute 1-1 relationships between entities but only probabilities differences. For instance the likelihood of you having one nose is higher than the likelihood of you having one arm. Design for multiple stuff from the beginning to save you some pain in the future.

Complying with unicode.

Complying with unicode is at heart a simple matter of understanding that 'an encoding of the data', 'the data itself' and the 'glyphs to represent it on a piece of screen|paper' are different things. Unfortunately this is still challenging to get for a lot of P* language programmers. If you're used to "print whatever" assuming it "just works" in your english language environment, it's very likely you're wrong.

More thoughts to come in the future!

No comments:

Post a Comment