Saturday, January 12, 2008

Intelligent software

It is unfortunate that computers, which promised to make our lives easier, often create more work for us. We get overloaded with mundane tasks such as making backups of important data, maintaining order in documents, processing bazillions of emails, reminders and meeting invitations, ignoring instant messages from colleagues, deleting spam – and the list goes on!


So it pleases me when companies add intelligent features to their products – features like search, automatic user-friendly backups, recognizing dates, phone numbers and addresses in emails. These and many other wonderful features save time, minimize the chance of an error when moving data between applications, and improve the overall flow of information. But if you're going to implement any sort of automation, make sure to do it right or not do it at all:


Yahoo! Mail wrongly recognizes 'this may' as a date interval


It is no secret that bad automation is far worse than no automation. The example above shows that it is not enough to have good intentions. You have to invest time in researching the problem. Or, with the case in point, simply testing your implementation thoroughly.

Thursday, January 3, 2008

Generic solutions and simplicity

I have been writing software professionally since the early nineties. I used to favor pure generic solutions. For example, if I had had to write a program that was to save the Earth, I would have made it generic enough, so that it could save the whole class of planets similar to the Earth. Or with just a little bit of specialization – every single planet in the universe. Or even every celestial body in the universe! See the problem yet? At one of my previous jobs this habit of mine finally peaked and the serialization library that I wrote while there was so generic that user-defined types – ready for it? – virtually serialized themselves. No? Oh, well. Actually, the "virtual" part was due to the limitations imposed by the legacy code. Otherwise the implementation would have been entirely generic, which modern C++ is so good at.

Of course, so often by the time you finish your fantastic "celestial body saver" you realize that the universe isn't really worth saving. Or that someone else has a better solution. It's not like I no longer believe that generic solutions are awesome and save you a ton of future effort, but this imaginary future might never come. So instead of worrying about the whole universe of problems, why not focus on the specific problem at hand while keeping in mind how the problem can exacerbate? Is other words, it is important to know when to stop. I believe it was Albert Einstein who said that everything should be made as simple as possible, but no simpler. These words are golden! I wish I understood the full meaning earlier.

Some people argue that complex tasks are inherently complex and require complex solutions. In fact, they add, you might even want a certain amount of complexity in your solution to counterbalance the complexity of the task itself. I don't know what they mean by that, but it's clear to me that the goal of any solution should be to embrace the "maximum meaning with minimum means," as Abram Games aptly put it. Applied to software development this would mean that you should include in your application as few features as possible, but not fewer. Just enough to solve the problem. Not those proverbial 20% of the features for 80% of the people, but the minimum number of features that solve the maximum amount of the problem.