The best software has a vision. The best software takes sides.
There’s been a lot of discussion around David Heinemeier Hanssons principle of “opinionated software”. Some people say that “to David, a piece of opinionated software is written in such a way that makes it easy to do things one way and ugly and difficult to do things another way”.
Maybe this approach “with a carrot and a stick” seams odd and old-fashioned, but i think its actually working and because of that, many people don’t like it.
Imagine, you’re using a product you like, you value its creator and especially his opinion and then, something you wanna do, doesn’t work because of obvious arbitrary restriction, you will be pissed for sure.
Certainly not all decisions made with a strong opinion are good, but i think, many of them made boldly had a reason to be done in a definite way and not another, often arising from the same reason you valued the creator of them before.
I’m writing this because i was really pissed when Rails 2.0 came out. It may be sound picky, but in Agile Web Development with Rails” DHH stated: “This fom of attribute accessor looks at the coluumn’s value. It is interpreted as false only if it is the number zero; one of the strings “0”, “f”, “false” or “” (the empty string); a nil; or the constant false. Otherwise it is interpreted as true.”, which means: A convenient method to add a question mark to attribute accessors to query them if they are true or false.
This due to the fact that there is an SQL standard that defines a datatype BOOLEAN but most of the RDBMS do implement them in their own way, most of the time as tinyint constrained to 0 and 1 (Oracle favours “y” and “n” for whatever reason) and so on.
I myself went with “t” or “f” as i can easily memorize it (true and false, obviously, sure, we can argue if i shouldn’t know about 0 being false and all other being true, i do know but the less i need to think about the obvious the more i can concentrate on actually doing something).
So with Rails 2.0 stuff breaks: DHH and the Rails team went with the MySQL approach: 0 and 1 only, 0 is false, 1 is true. This is fine as for example MySQL defines constants like TRUE and FALSE, that although being 1 and 0, conforms to the standard.
As i saw pieces of app failing with the new release (important parts like things being public or not, blocked users and so on), i was angry… “The bad guys destroy my toy” boohoo and i filed this ticket.
After thinking about (and actually changing my enums(‘t’,’f’) to the pseudotype boolean), i think it’s the right decision. As the model existed before i started working with Rails, i didn’t use migrations to generate tables, which is pity as with this decision, i would get the right datatypes in all supported databases. But even though, i like things being conform to a standard most vendors seem to listen to.
Without the Railsteam willingly breaking compatibility and being opinionated, i would have sweared less on the one side but i would have missed the opportunity to do some justified rewriting.
For me it’s ok to be opinionated and a little bit rockstar like, if you got the right reasons. I myself tend to be opinionated enough on my own work but i can defend my decisions most of the time.
It’s not always nice to be corrected and the corrector maybe doesn’t seem like a teamplayer, but i can life with the concept of the “Benevolent Dictator” when the product does the things its expected to do good and isn’t a “creative” mess.
Just in case you haven’t seen the great movie Borat or are totally unaware to irony, i don’t think that software with an opinion and attitude suck.
No comments yet
Post a Comment