Podcasts are a great way to get exposed to these new things: if you commute, jog, travel, you can easily use that time away from the computer to get better informed and reflect about our field.

I have a 20 minute walk between home and my office. That’s more than 3h of free time per week that I can spend thinking, listening to music or getting entertained and educated through relevant podcasts.

These are my preferred shows so far:

Hanselminutes
A 30 minute or so podcast about technologies, usually closely or distantly related to Microsoft development. Scott is an excellent interviewer and his blog is a must read too.

Herding Code
A 60 minute show with a bunch of well-known developers, K. Scott Allen, Kevin Dente, Scott Koon (Lazycoder), and Jon Galloway discussing wide-ranging topics with their guests.

.Net Rocks
The unavoidable 60 minute grand-father or all .Net podcasts. Funny and always informative. Also check out the related DnrTV for on-topic screencasts, excellent for getting started on a new technology.

The Polymorphic podcast
A nice podcast, the host, Craig Shoemaker, is a great inteviewer. Only drawback is that shows are not regularly produced.

The StackExchange podcast
Sometimes random, mildly irritating at times (guests sound quality, audio sync between guest, ramblings about Stackoverflow’s principles) but usually both enlightenning and funny. Topics revolve around Stackoverflow and the various StackExchange sites. It’s always worth listenting to Joel Spolsky, he tends to see clearly in an industry that often borders on the BS.

This Developer’s Life
Last but not least, a beautifully produced podcast that covers more philosophical topics through interviews and real-life experiences. It’s not about technology, it’s about the human aspect of being a coder, and what it means to be one.

Whichever you choose, any of these podcasts are bound to expand your knowledge, educate and entertain you!

Good graphic designers who work on User Interfaces are too few and far between, and large organisations will take time to get staff with a sufficient level of expertise to be useful in developing meaningful WPF/Silverlight applications.
Until now, the bulk of the development effort was done by developers. Most ISV only have developers onboard.

As far as I can tell, it seems that main reason behind this slow adoption is that WPF/Silverlight has only been noticed by developers and they don’t know what to make with it.
WPF/Silverlight are not really developer-friendly: the development infrastructure is there but we’re left with a blank canvas and nothing to drag and drop onto it.

There will be a great gap, probably lasting a few years, before there are enough experiments in these new user interfaces that some useful lowest common denominator can be exploited by non-designers.
We’ll have to wait for tool vendors to provide the bulk of user interface blocks and for a few new patterns to appear before all the designer-challenged developers like me can make decent interfaces without requiring a professional graphic designer in their midst.
In the mean time, we’ll probably have useless, but pretty, applications, some useful, but ugly ones and a lot of people scratching their head trying to couple the designers and the developers in a working relationship.

If you are from North America and a handful other countries 04/05/01 would mean 5th of April 2001.
If you’re in Asia or some eastern countries, if could be 1st of May 2004.
For the rest of the world, it would look like 4th of May 2001.

We cannot ignore any longer the importance of writing dates in a format that is understandable by everyone.
Still too often, web sites -even big companies- with a global audience state dates in a format that is probably obvious where they live but not consistently so to everyone else.

Developers are sometimes guilty of this sin, as can be seen in the format chosen to specify dates in Microsoft Access SQL, which requires that hard-coded dates be formatted in the US rather than the more neutral ISO8601 format.
I wonder how many bugs that little egocentric feature caused in business applications that where developed by foreign coders…
I know it also happened to me at least once…

The worst thing is that when you write 04/05/06, you may very well have thought about the rest of the world and meant DD/MM/YY; alas, unless the context grants us some clarification or the actual date is unequivocal, there is sometimes no way for a lot of us to know for sure what you really meant.

We should ban the use of the short date format in communications that may be read by more than 3 people, in today’s world, that’s pretty much all communication.

Instead a simple format such as 05MAY2006 is clear an unequivocal: it’s easy to read and understand, regardless of where you live.
You’re free to add spaces, dashes, dots, comas or slashes to it if you want, you can use 2006MAY05 if you prefer or even MAY05,2006, whatever pleases you: it still remains readable.

The rule is simple:write the year in full and never write the month as a two-digit number, that’s reserved for the day

The point is that you, me and the rest of the world can read it and understand exactly what was meant; it’s an easy problem to solve.
Surely that means something to you?

References

• http://en.wikipedia.org/wiki/Date_format
• Does you code pass the Turkey test?

If you don’t know him then he’s the mastermind being similar projects that centre around a simple premise: make humans do the work that computers can’t do.
One of his on-going projects is the ESP Game where 2 online players are trying to come up with a common description of a random picture. It’s apparently an addictive game and it helps solve a problem that computers are terrible at today: describing accurately the content of photographs.
Google is using his research to make image search more useful by returning content more relevant to your queries.

So, what’s the relevance with the CAPCTHA?
CAPTCHASs were invented to resolve a simple problem: stopping computers from automatically filling-in web forms to create accounts on popular free services that they would use to send spam from.
They are a visual version of the Turing Test, elaborated by the WWII genius cryptanalyst Alan Turing as a way to test how far machines could behave like humans: not knowing who she was interacting with, if a person could not tell the difference between a human and a machine, then the machine passes the test. It’s a measure of the success -or lack of- of artificial intelligence and the idea spawned many others, including CAPTCHAs.

CAPTCHAs simply require that small problem be solved before a web form can be submitted. Typical problems include blurry and distorted images of text or numbers that would be very hard for computers alone to decipher, but that our brain has no problem solving.
There are an estimated 60 millions of CAPTCHAs being solved by human beings every single day. That’s a huge amount of lost brain power as nothing really useful comes out of it (apart from preventing spam, of course).

reCAPTCHA‘s genius idea is to use that brain power to solve a problem that we would actually like computers to solve: digitizing books.
There are millions of books that were printed in the days before computers became ubiquitous, and there exist no electronic version of them except scanned images of their pages.
Optical Character Recognition software is getting very good, but when the scan is of poor quality or the book is old, many words cannot be automatically recognised.
Humans on the other hand are quite good at reading words, even if they are badly distorted and barely recognisable.
Instead of making up a distorted image that you would have to recognise, reCaptcha simply presents you with 2 words: one it knows and one it doesn’t and you’re asked to guess both.
Every unknown word is checked multiple times by different people and you thus end-up with a very accurate interpretation of the word that can be fed back into the electronic version of the book being scanned.

CAPTCHA do not entirely solve the problem of spamming, but they are an financial issue to spammers: automated electronic system cannot solve good CAPTCHAs, so some spammer rely on low-paid humans to do the dirty work for them.

It’s fine by me: poor people are getting paid to do something useful (help digitise books) and spammers are wasting their money doing so. In my case, they lose even more, because I use moderation to read comments before they are visible and Askimet to detect spam, which means that however hard they try, their spam never gets anywhere anyway.

In the fight against spammers, it makes me happy to know I’m costing them something for a change…

References:

• Breaking visual CAPTCHA
  http://www.cs.sfu.ca/~mori/research/gimpy/
• Vulnerabilities of some CAPTCHA implementations (reCAPTCHA isn’t)
  http://www.puremango.co.uk/cm_breaking_captcha_115.php
• Luis Von Ahn’s website
  http://www.cs.cmu.edu/~biglou/
• Lecture on Human computation by Luis von Ahn (technical, but very inspiring)
  http://video.google.com/videoplay?docid=-8246463980976635143
• The Internet Archive, benefiting from solving ReCAPTCHA, also a incommensurable source of free books
  http://www.archive.org/details/texts

When you start looking into all these platforms you can be blown away by the ease of implementation and elegance of some; your head spins at all the features and claims being made and it becomes hard to achieve a rational decision.

I’ve been faced with that very issue recently and it sucks. Actually, the time spent investigating all these possibilities is really what is being sucked away.
Of course, learning about new technologies is not just fun, it’s also essential: you have to keep on top of what’s new and decide if you want to join in on the fun or just stay comfortably where you are.

I also realized that you need to get away from the coolness factor of each these much touted technologies and actually try to be objective.
During my investigation, I tried to decide what were the really important factors that I should consider to make a rational choice.

I came up with the list of the following 10 questions that I think everyone should ask themselves when choosing a platform for an important project.

1- Is the platform wide enough?

New technologies that can show amazing productivity get all the buzz. After all, that’s what we developer want: enough with the nuts & bolts! Give us a toolbox with all new shinny power tools! The problem is that often these technologies are impressive, but looking beyond the sample projects into what actual users get confronted to, you start noticing discussion threads that should obviously signal that the platform is not wide enough.
Choosing a technology that hasn’t achieved its goals can be a huge problem down the line: you implement 80% of your project in record time, only to realise that the platform you chose doesn’t support proper cross-browser detection, or that its implementation of security is way too lax, or that it only support XML for data storage and now you actually need a real database for performance reasons…
In those cases, you can of course develop those areas yourself and contribute to the project, but doing so supposes that you planed it all along and you factored that in your schedule, both in time and in cost.

2- Is it popular?

In other words: are other professional people actually using that platform in real life? I’m not talking about Joe Developer using it for his local community church website. I’m talking about businesses or large organisations actually using that software platform successfully.
If all you need is a simple 3 page website, then professional popularity amongst the Top 500 business companies is probably not that important. On the other hand, if you plan to build a large project, or you know that your project could grow large in the future, then you probably want to ensure that others have taken it there before you.

3- Is it mature?

Has the platform existed for long enough that it went through enough abuse to withstand almost anything you can throw at it?
A technology that is only a couple year old may be too young to have evolved to the point where it actually can solve most common and not-so-common problems. Technology evolves through iterations: each one is a good long hard look at what didn’t work and tries to fix, improve and extend.
A young technology may be more cutting-edge and exciting, but when you need to commit to it for a big project, its age may quickly come as an issue; its shinny surface may blind you to the black holes waiting below…

4- Are local developers available?

Always think about the future. When you’re gone from the project, who is going to look after it? Getting a web project entirely in Rebol may be cool and fun, but how many people in your city actually use that thing anyway?
Aren’t you creating a liability if you’re dead-set on choosing a platform that cannot be maintained?

5- Is it scalable?

Most projects start small but dream of ending-up big.
It’s usually fine at the beginning when the number of users and visitors is manageable, but what happens when you start to be successful?
After all, that’s why we craft our projects: we want them to succeed, we want the world to see them. When the world starts coming though, will the terrific platform we’ve chosen break at the seams?
How much overhead does the platform create? It is flexible in its database support? Is there a way to implement clustering or persisting sessions accross multiple servers?
What’s the cost in memory and CPU resources? How many simultaneous connections can you get? What are the bottlenecks? What do you need to do to compensate for them? How much would it cost?

6- Do you have control?

Some frameworks work hard for you and can make you really productive. Sometime though, they try too hard and hide too much from you.
When a feature doesn’t exactly work the way you want you have to dig deep into the entrails of the beast to make sense of it and change its behaviour.
A platform that was all nice and pretty can get very dirty and complex inside, making it difficult to adapt to your needs.
A platform should do most of the hard work but still allow you to redefine its default behaviour without much hassle. It should be built with extensibility in mind, making easy thing easy and difficult things possible.
A case in point are 4G development platforms: they usually have a fairly narrow field of expertise and tend to use graphics and nice simple paradigms to quickly build complex tasks but when you are faced with a specific issue that hasn’t been solved by the platform, you often have to resort to ugly hacks to get around their limitations.

7- Does it satisfies the essential constraints for your project?

When being blinded by something cool, we often become skewed in our judgement and guilty of lowering the importance of constraints that are actually critical for our project.
In all honesty, I really wanted to use Ruby on Rail, and I liked the principle and elegance of it so much that I came to seriously consider it, that is, until I came to my senses and looked into something that is critical to my project: support for complex Asian languages.
Ruby is being developed in Japan, so you could think that it should be able to handle complex ideographic characters well.
Turns out that the Japanese are not terribly fond of Unicode and, unless I’m mistaken, prefer to use Code Pages instead. The result is that Ruby doesn’t have great support for Unicode, and that sucks.
That’s why Unicode was created: to attempt to simplify all this patchwork of implementations that are not compatible with each other.
Because I needed to be able to handle English, Mandarin, Cantonese and probably any other language out there, Unicode is the only viable option to abstract the issue of language enough that it becomes manageable.
So because of Ruby’s poor support for Unicode, it would not be rational to use Ruby on Rails for my particular project as it would probably greatly increase the complexity and hacks necessary to manage complex Asian languages in a unified and simple way.

8- Documentation?

All framework have a more or less steep learning curve: you need to think differently to adapt to the particular framework’s frame of mind, so to speak.
Make sure that the framework has a lively community, that it has more documentation than you can swallow and that documentation is well organised.
Make sure also that there are samples, tutorials, webcasts, videos or whatever that cover the principle aspects of it.
A beautiful framework no-one talks about means that no-one will answer when you have a question. A beautiful framework without documentation is useless. A beautiful framework with lots of disorganised docs means that you’re going to waste a lot of time experimenting instead of building your project.

9- Support?

Here I mean support in the wide sense of the word: who is behind the framework. Are they likely to stay in business long after your project has been completed?
Are they commercial or Open Source? In either case there are issues for and against: a commercial venture backed by a small company may falter and disappear overnight. Similarly, an exciting open source project managed by only 2 people can suffer the same fate when they decide to move on. Support also includes what help is available to you when you encounter issues. Is there any guarantee that you could have your important technical questions answered?
If you encounter a large issue, is there someone to help you?
I would contend that the best and most serious projects should have professional help available: you can always fall back on paying someone to help you through, whether it’s the original developers, a paid-for support hotline or a third-party specialist, it’s important that you know you can get your answers when you’re stuck.
Developing for an important project without safety net is dangerous: you can waste a lot of time and effort, endangering the very project you are undertaking, if you stumble on a problem you cannot solve yourself.
Large frameworks like .Net or big Open Source projects usually have enough users and support groups and specialists that it’s likely any question you may have has already been answered somewhere or that you can pay someone to help you out when you need it most.

10- What do you know best?

Every framework is based around a particular data-management model. Every framework is built with a particular programming language in mind. Every framework demands that you learn something new. How comfortable are you with the requirements? how long is it going to take you to start to get really productive?
Like their real-world counterpart, it can take very little time to learn a new language’s words and syntax but it takes years to become proficient in it. A framework adds another layer of abstraction that you will need to get experienced at.
If you need to both learn a new language and a new framework, chances are that you are at best months away from being able to churn code without having to look into the documentation every 5 minutes.
Learning new languages and concepts is necessary, but again, if you chose that route you must be sure that your project has that learning curve built-in, otherwise you’re going to move at the pace of a turtle when in fact you chose that particular framework because you though you would be more productive and faster than a sparrow.
If you chose a new framework, make sure that you already possess most of the knowledge it requires: in my particular instance, I chose .Net and C# because I have already worked in that framework and I know it can tackle the project without me having to waste too much time on learning the platform rather than implementing the project.

We all should seize any opportunity to learn something new. Learning is often more exciting than doing the same old thing over and over again and it’s a necessary part of staying in business. Curiosity is an excellent quality that must be nurtured and indulged.
The issue is when to do it.

Choosing a new development framework is not easy. The best way to tackle the problem is to pose it as a risk analysis study.

The framework you chose should simply be the one that poses the least risk to you succeeding your project.

I used to love/hate these. I would hate them when they were clearly biased in the favour of the customer (for these kind of large multi-million dollar contracts, the customer imposes his rules), and I would love them -or at least appreciate them- when they were fair and balanced as they would clarify every party’s duties and responsibilities.
After leaving that world and starting my own IT business I wanted the relationship with my customers to be as non-threatening and amicable as possible.

I decided -stupidly- not to have stringent legal documents defining the terms of the sales. What I would do instead was spend time making sure that the customer understood everything by explaining at length what they were getting and ensuring that they were no misunderstanding. In my written offers, I would painstakingly describe the technical part of their project and clearly mention what they were getting, when and at what cost.
My rationale was not to scare customers away and instil trust by being verbose and friendly.

Well, that worked for a little while until a particular customer ordered a server as part of a larger web-site project.
Once she confirmed her order to me I promptly ordered the hardware from Dell and paid for it in advance (their requirement for processing the order). A few days later, she phones and calls the whole project off, a project we’ve been spending time on for nearly 2 months.
She just happened to realise that she wouldn’t have time to build the content for it.

Well, that’s where not having stringent sales conditions bit me in the arse. When I told her I already ordered the hardware and couldn’t refund her until I got my own refund from Dell she started to spin her own fantasies and self-indulged delusions and started to treat me like a common criminal. She became a complete lunatic and I really didn’t know how to handle her any longer. I even gave her copies of my correspondence with Dell, bank account statements to show that the server was paid for…
In the end, I tried to explain where her assumptions were wrong and told her she would get her refund at the latest on a certain date, based on what Dell told me would be the longest waiting period. Turned out that it took 6 weeks to get my refund, just in time for hers.

The morale of this story is that:

• you shouldn’t be naively stupid and think you can base your relationship with a client on trust only.
• you should have conditions of sales accessible on your website and refer to them in all your correspondence with your clients.
• you shouldn’t work with people who can have a propensity for confabulation. That particular customer was a provider of dubious alternative medicines and was clearly a lost cause to reason. My first instinct and moral judgment of not working for her was right and I should have listened to it instead of just thinking about the much-needed cash it could get me…

…which bring me to the last lesson: don’t sell your ideals for money, however bad you need it.

One self-inflicting problem I’ve often been confronted to is over-engineering: I tend to over-think, over-design and over-anticipate.
Sometimes it’s good to just spend time trying to make your code more modular and as future-proof as you can, but often, it leads to code that has no real use right-now, and that ends up having to be modified because when you need it, it’s not in the form you’ve implemented it originally.
This is an Extreme Programming practice aptly named You Aren’t Gonna Need It.

A classic example of YagNi that I am paying dearly is a large application I’m working on at the moment (at least large from the perspective a single developer).
It’s a fairly complex database application with an equally demanding winform GUI layer in C# on top.
I built the GUI in a very modular fashion: each bit of information that could be grouped has its own User Control, sealing its particularities.
Then each of these controls is used in panels that embody another layer of functionality.
Each panel is then loaded as needed into a form that display the panels on demand.
The issue is that I now have to make major changes to the application and there are too many layers in these controls, making code hard to change.
I had built it this way for re-use, thinking that it could be useful to have independent specialized controls, say for entering addresses, or customer details, etc.

Well, each of these controls took me a lot of time to craft, trying to make them as independent upon my particular implementation as I could. It turns out though that I’ve used each control no more than once -maybe twice for a couple- in the whole of the application, and I now realize that it’s unlikely that I would get another job that would require the exact same user-interface broken down the exact same way.
So my uber-GUI controls are mostly a waste of time and complexity.

I should have simply created the forms directly, using partial classes (a new .Net 2 feature) to separate each logical part into something manageable.
My application would have been faster to develop and faster to run, with a lot less of unnecessary layers of abstraction.

I’m having a hard time with that, but I’m getting better, hopefully…

The main issue is that IE7 is now yet-another browser that web designers have to test and include support for.
It may not be a huge deal for most sites, but some do rely on specific browser versions. In my case the problem arose when I tried to connect to my company’s online bank account. For security reasons (?!) it only supports IE6, not even Firefox so it’s one of the few sites that requires Internet Explorer. Problem is that IE7 replaces IE6 entirely, with the unfortunate result that I now can’t connect to my bank accounts (company accounts only, the portal for personal accounts supports Firefox).
So I’ve had to remove that beta.

That is certainly a specific issue, but it will be interesting to see how fast websites that rely on specific versions of browsers, be it for security reasons (because they want to simplify their development to a manageable level and support well a single browser) or because they rely heavily on CSS and JavaScript, how fast these websites will adapt.
Early adopters of Vista will now doubt have a few -temporary I’m sure- surprises.

I think Microsoft made a big mistake when they decided to stop development of IE6 and not incorporate any more improvements into it.
Maybe the company was under too much legal spotlight at the time and leaving the scene for a while was a move to appease those who were concerned about its monopoly on internet browsing.
The unfortunate side-effect was that the browser millions relied-on had still some important flaws. Its User Interface and usability has now been overtaken by Firefox and Opera which benefited from the development interrruption of IE.

I am not sure if IE can become better than Firefox in terms of extensibility: Firefox sports thousands of extensions and themes to customize it. I’ve got quite a few useful ones that are certainly particular to my way of browsing the net. How is MS going to integrate that into IE7?
What made Firefox popular was its focus on carrying-on where IE6 had left and offering a better browsing environment that could be customized with all the widgets and utilities that you wanted.
If MS doesn’t incorporate the same level of extensibility, it will carry-on losing a big share of its browser market to Firefox, at least in the personal user world.

But Maybe Microsoft doesn’t care too much about browser wars any longer.
When you approach perfect standard compliance, which browser you use to render the content isn’t important any longer. Since MS failed in the past to tie revenues to the browser itself (remember the ill-fated channels that would bring commercial content to your browsers back in the days of IE4? No?, well I’m not surprised…) the incentive for building a better browser is elsewhere.

One of the reasons that may be motivating MS is that a lot of its other products are increasingly dependent on the Internet. In a corporate environment, almost all business-oriented services are accessed through a web interface of some kind.
Microsoft must ensure that it retains the monopoly on these implementations to keep control of the complete user experience.
If MS wasn’t pursuing its IE development, more companies would start to look at alternatives, not only to IE, but also to larger expensive products like Exchange: once you accept that IE isn’t needed to offer rich client-side user interfaces, and that you don’t need Exchange either, you’re endangering Microsoft hold on the corporate market somewhat.
So going further and ensuring tight integration of its products together is paramount.

IE7 is also terribly important to MS on the home user-front: making sure that users use the same browser both at home and at work ensures that they are more likely to stay with what they know rather than accept using a new browser, that may require retraining for some.
That reason may seem feeble, but it ensures that the vast majority of people is not exposed to other alternative technologies.
Without IE7, that risk becomes real as more and more savvy users and corporations are turning to Firefox for its increased security (or at least for the fact that it is a lesser target to malware).

That factor alone may obviously not be sufficient to force a company to move away from MS, but it may be sufficient to poison the mind by making people to consider alternatives they would otherwise be somewhat reluctant to contemplate by fear of the unknown; a fear that MS has not shied away from exacerbing through its FUD campaigns.

Of course, all this requires a few grains of salt, I may be completely wrong…