Thursday, February 10, 2011

Best practices? there is no such thing.

There's one thing everyone knows about Perl: There's more than one way to do the same.
And that, that same single thing, is viewed as a good thing for pro-perl people, and as a bad thing for anti-perl people.
There are obviously good ways to do something, and bad ways. There can be better ways. But there's no way a single way should be the best.
Perhaps, and only perhaps, there could be a best known way to do something. Perhaps Bresenham's algorithm was the best one to draw a line, until a better one came. Which is the best one nowadays? Well, it depends on the lenght of the line. And on the slope. And on the machine executing it.
I'm sick of hearing people preach of best practices to do something or the other where using these best practices means a much larger code to write, bloat, inefficient code, etc, while providing absolutely nothing better than a different way to do it. They sure are better in some cases, but not always. And when something is not always better, even if there is a single case of not being better, it's of course not the best.
Anyway, having a best something would, by definition, kill all innovation and improvements, because... how could someone even imagine doing something better than the best?

Friday, February 4, 2011

Managing complexity

Is never easy, and that's why so many people fail to do so correctly.
I've been somewhat forced to develop an application using a framework. I really hate this framework. Any little change, any tiny modification, anything which could be done in half an hour takes us days to acomplish. Why? because this framework is the wrong tool for our problem.
The framework was developed internally to solve one problem, and I hope it's right for that. But now a completely different team must use it for a completely different problem. And nothing works. Of course.
We don't know it, we have never used or even seen it before. We don't have documentation (because there isn't any, of course).
Most of our work is via trial and error. We also do some reverse engineering, and study the sources we have, and studying the sources is what makes me ill.
I can see how much work has been put there. How great attention to small details has been put there... for very concrete, special, narrow cases...
The moment where you try to do something slightly different than that which was expected... everything fails.
You want to filter your data? it's easy, you place that filter there and everything works automatically.
Ok. Now how do I put this other filter there?
what? which other filter?... well,  that was not thought of, it's not possible.

So, after spending days to try to know how something worked, when I want a slightly different solution... it's simply not possible. The only way? study the sources and replicate everything with the small changes required for the new specific case.

Hiding complexity for a specific case will never work. When will many of these high qualifications, high rank, high pay "software architects" realize they are doing it wrong?