It was a dark and stormy night, and a friend was giving me a ride home. I was sitting in the back seat as his wife was telling us that she had joined a political party. "Isn't democracy wonderful", she ended. I hesitated for a brief second, then shot back: "Democracy is shit!"
That was the starting point of a vigorous debate on the pros and cons of democracy. She was getting more and more agitated, miserably failing to deflect my arguments, or making her own arguments stand. After a while my friend started to laugh, and, knowing me, revealed that I was just playing the devil's advocate.
And I was, but democracy* has its limitations, and should be used with caution outside the realm of politics.
In an agile team there is little room for democracy. You decide what is right on your own, and if the decision proves controversial, or if you feel you need input, you come to some kind of consensus after a discussion within the team.
What if the team simply can't agree on the best way forward? Then the team has failed. If it's a rare occasion, accept defeat, have a vote (or not), make a decision, then move on.
A team that often fails to agree on important issues, isn't working very well, and democracy is probably not going to save it.
Planning poker might look like democracy, but it isn't. Planning poker voting is part of a process to get consensus around what a task means, and how difficult a task it is. Time estimation has been shown to be detrimental in its own right, but that has nothing to do with democracy. (And estimation may be necessary, despite the drawbacks.)
* For this post I'll define democracy as the process of voting about something, with the majority deciding the outcome.
May 8, 2013
Oct 8, 2012
Fun with property files
Let's say you have a property file (myprops.properties):
With a localized version (myprops_sv.properties):
Now add a spurious backslash to myprops_sv.properties:
What do you get? When using the localized version you get a mix of English and Swedish ("No", "Ja"). Well, you don't really get "Ja", you get "Ja \dialog.no=Nej", but that's hard to spot if it's used for a fixed width button... Took a while to figure that one out.
dialog.yes=Yes dialog.no=No
With a localized version (myprops_sv.properties):
dialog.yes=Ja dialog.no=Nej
Now add a spurious backslash to myprops_sv.properties:
dialog.yes=Ja \ dialog.no=Nej
What do you get? When using the localized version you get a mix of English and Swedish ("No", "Ja"). Well, you don't really get "Ja", you get "Ja \dialog.no=Nej", but that's hard to spot if it's used for a fixed width button... Took a while to figure that one out.
Sep 26, 2012
On the "Intel Inside" Sticker Question
The Dumbest Question I've Ever Heard has resurfaced at Daring Fireball.
The reporter in question was ridiculed as the Intel Sticker Guy and called brazenly moronic at the time.
"Can you say why you all are not participating in the "Intel Inside" program, putting the stickers on your new or previous Mac?"
It is actually an excellent question. The job of an interviewer is not to appear smart, but to bring out the best from the interviewee. The purpose of an interview question is not to inform the interviewer, but to inform the listener.
Everyone PC maker using Intel, except Apple, put stickers on their PCs. It may be a small detail, but it really goes to the heart of Apple's product philosophy, and that seemingly innocuous question provoked an emotional response, reflecting that philosophy.
Apple must have been overjoyed at being given the chance to explain how they were different from other computer makers. And I believe that was what the reporter intended.
The reporter in question was ridiculed as the Intel Sticker Guy and called brazenly moronic at the time.
"Can you say why you all are not participating in the "Intel Inside" program, putting the stickers on your new or previous Mac?"
It is actually an excellent question. The job of an interviewer is not to appear smart, but to bring out the best from the interviewee. The purpose of an interview question is not to inform the interviewer, but to inform the listener.
Everyone PC maker using Intel, except Apple, put stickers on their PCs. It may be a small detail, but it really goes to the heart of Apple's product philosophy, and that seemingly innocuous question provoked an emotional response, reflecting that philosophy.
Apple must have been overjoyed at being given the chance to explain how they were different from other computer makers. And I believe that was what the reporter intended.
May 7, 2012
Java is Still Free Software
There's a lot of fud floating around regarding Java and Oracle's enforcement of its Java related rights. E.g.
If you if can abide by the terms of OpenJDK, you are as safe as with any other free software*. And indeed, Oracle has not gone after any OpenJDK licensees, nor have they given any indication they would want to do so**.
The API question is yet another red herring that is deliberately used by Java bashers to muddy the waters. If you accept the GPL license, you have licensed the whole work, including any copyrighted parts of the API. If API:s are in fact covered by copyright, we have a real problem, but an industry wide problem, maybe I'll comment on that in some other post, but it's not a Java problem.
Those are the facts, but where do I stand? I would have wanted Sun to endorse the Harmony project. I would have liked for Google to come to terms with Sun before rushing headlong into developing Android. Oracle could have been more lenient. And I definitely would have preferred an Apache style license over GPL for OpenJDK. But the trial is real, and it has hurt Java, Google, and Oracle immensely, regardless of the final outcome.
* I use the term free software rather than open source, since it's a more fitting description of GPL style licenses.
** If you download Java from Oracle you subject yourself to a completely different "binary" license.
"If the verdict that Android infringed copyrights stands, it could put programmers in a difficult situation. Java is an open source language, but now it's not clear how free programmers are to use it, since Oracle has said that anyone following the Java APIs—which are basically sets of instructions about how to use Java—needs a license." Ars Technica/Joe MullinGoogle's problem, to the extent that they have a problem, the trial is far from over, is that they have chosen to not license Java from SUN/Oracle at all. In particular, they have chosen to not use the GPL licensed OpenJDK . It's perfectly clear what the GPL license is, and how it works, and the validity of the license have been upheld in several courts of law.
If you if can abide by the terms of OpenJDK, you are as safe as with any other free software*. And indeed, Oracle has not gone after any OpenJDK licensees, nor have they given any indication they would want to do so**.
The API question is yet another red herring that is deliberately used by Java bashers to muddy the waters. If you accept the GPL license, you have licensed the whole work, including any copyrighted parts of the API. If API:s are in fact covered by copyright, we have a real problem, but an industry wide problem, maybe I'll comment on that in some other post, but it's not a Java problem.
Those are the facts, but where do I stand? I would have wanted Sun to endorse the Harmony project. I would have liked for Google to come to terms with Sun before rushing headlong into developing Android. Oracle could have been more lenient. And I definitely would have preferred an Apache style license over GPL for OpenJDK. But the trial is real, and it has hurt Java, Google, and Oracle immensely, regardless of the final outcome.
* I use the term free software rather than open source, since it's a more fitting description of GPL style licenses.
** If you download Java from Oracle you subject yourself to a completely different "binary" license.
Jan 4, 2012
SOPA Amendment
According to my sources, an addition to SOPA is in the works. This addition is spearheaded by the Retail Industry Association of America(RIAA), text taken from an early internal draft:
"The problem of shoplifting is a widespread scourge in the retail industry. Shoplifting costs business owners billions of dollars every year, and hurts consumers as well. To make matters worse, many jobs are lost.
We believe that the general principles of SOPA can be applied to the retail industry with some small additions. Shoplifters often live in apartment buildings, where they stash and consume their loot. It is only fair that the owner of the building is responsible for its tenants belongings.
Our modest proposal is that, if a tenant is found to be a shoplifter, all tenants of the apartment building in question should be evicted to prevent further crime. Furthermore, the address of the building should be removed from all maps to prevent accomplices from visiting. All payments to and from the owner of the building should be stopped.
These measures should stay in place until the owner has put safeguards in place to prevent further crime.
Since it can be difficult to prove that someone is shoplifting, we believe that mere suspicion should be enough to start the above procedure. If further investigation proves the allegations wrong, the measures taken can be reversed with no harm done.
We would also like to use this opportunity to state that we are committed to fair, reasonable and balanced law for the general public, complemented by voluntary ethical conduct code for the retail industry itself.
Noh Wan - on behalf of
RIAA"
"The problem of shoplifting is a widespread scourge in the retail industry. Shoplifting costs business owners billions of dollars every year, and hurts consumers as well. To make matters worse, many jobs are lost.
We believe that the general principles of SOPA can be applied to the retail industry with some small additions. Shoplifters often live in apartment buildings, where they stash and consume their loot. It is only fair that the owner of the building is responsible for its tenants belongings.
Our modest proposal is that, if a tenant is found to be a shoplifter, all tenants of the apartment building in question should be evicted to prevent further crime. Furthermore, the address of the building should be removed from all maps to prevent accomplices from visiting. All payments to and from the owner of the building should be stopped.
These measures should stay in place until the owner has put safeguards in place to prevent further crime.
Since it can be difficult to prove that someone is shoplifting, we believe that mere suspicion should be enough to start the above procedure. If further investigation proves the allegations wrong, the measures taken can be reversed with no harm done.
We would also like to use this opportunity to state that we are committed to fair, reasonable and balanced law for the general public, complemented by voluntary ethical conduct code for the retail industry itself.
Noh Wan - on behalf of
RIAA"
Dec 2, 2011
Yammer and Scala
What does this mean? :
I have no idea, but I do know that List(1,2) ++ List(3,4,5) yields List(1, 2, 3, 4, 5). No surprise there. According to Yammer, my faith that ++ does indeed concatenate lists leads to "cargo-culting snippets of code as magic talismans of functionality". Apparently, I must scrutinize and analyze each and every last letter of the method signature to avoid falling into the cargo-cult trap.
It looks to me that Yammer have invented problems where none exists. "Understanding" is a vague concept, but if you have good abstractions, you don't need to understand why something works, only how. At least not until you do need to know.
I'm referring to the Yammer moving away from Scala post btw.
Regarding the Scala community, I'll agree that it's immature. There is no consensus of what good Scala code looks like, and there is a lot of academic noise. An organization that is serious about Scala development needs to come up with their own programming guidelines and maybe also their own utility libraries. Failing to do so will result in code styles all over the place, and an impossible maintenance situation. I expect the Scala community to converge towards a common code style over time, but we're a long way off yet. Today, Scala is mostly driven by academia and hobbyists such as myself, but that will change with industry adoption of Scala.
I have never done any serious performance tuning in Scala, but I'm sure the advise on how to improve performance is accurate in the right context. But in most cases, a difference in an order of magnitude or less is irrelevant, and I from what I hear about e.g. Twitter, when performance is critical, Scala has delivered. Maybe Yammer's needs are different, and can't be met by Scala.
At the end of the day, Scala is just another language, suited for some purposes, but not all.
PS.
I wrote about the academic mind set here, here, and here.
def ++ [B >: A, That] (that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
I have no idea, but I do know that List(1,2) ++ List(3,4,5) yields List(1, 2, 3, 4, 5). No surprise there. According to Yammer, my faith that ++ does indeed concatenate lists leads to "cargo-culting snippets of code as magic talismans of functionality". Apparently, I must scrutinize and analyze each and every last letter of the method signature to avoid falling into the cargo-cult trap.
It looks to me that Yammer have invented problems where none exists. "Understanding" is a vague concept, but if you have good abstractions, you don't need to understand why something works, only how. At least not until you do need to know.
I'm referring to the Yammer moving away from Scala post btw.
Regarding the Scala community, I'll agree that it's immature. There is no consensus of what good Scala code looks like, and there is a lot of academic noise. An organization that is serious about Scala development needs to come up with their own programming guidelines and maybe also their own utility libraries. Failing to do so will result in code styles all over the place, and an impossible maintenance situation. I expect the Scala community to converge towards a common code style over time, but we're a long way off yet. Today, Scala is mostly driven by academia and hobbyists such as myself, but that will change with industry adoption of Scala.
I have never done any serious performance tuning in Scala, but I'm sure the advise on how to improve performance is accurate in the right context. But in most cases, a difference in an order of magnitude or less is irrelevant, and I from what I hear about e.g. Twitter, when performance is critical, Scala has delivered. Maybe Yammer's needs are different, and can't be met by Scala.
At the end of the day, Scala is just another language, suited for some purposes, but not all.
PS.
I wrote about the academic mind set here, here, and here.
Oct 31, 2011
Scala Application Programming is not Math
Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.- Edsger W. Dijkstra
There is this notion that programming is doing math. It 's not true. Or to put it in a more nuanced manner: It is not true in any meaningful way for an application programmer like me.
I realized how difficult it is to speak to non-application programmers from the reactions I got to last weeks "How to not learn Scala fundamentals". We live in different worlds, me and academia. I tried to expand on my arguments in the follow up, but I probably missed the mark.
The thing is, m.map { t => val (s,i) = t; (s, i+1) }, probably is elegant, and maybe even easy to read for someone exposed to abstract functional code all day long. But for someone who uses Scala as tool, not to improve Scala, but to solve real world problems, abstract descriptions are more or less opaque. We can't easily pick up our rusty university ML experience (if we have that at all) and wrap our heads around "elegant" code like the snippet above. And we shouldn't have to.
If Scala is going to be a main stream language, usable by main stream application programmers, we need to acknowledge that most programmers don't ascribe to the maths based approach to programming.
If you learn Scala without understanding how it all works underneath, you will be less efficient, and sometimes a leaky abstraction will pop up and bite you. But that's ok. You'll still be better off than if you stick to Java. And you will understand more in time, and you'll learn to handle surprises better too.
Scala can boost productivity a lot compared to Java, and you don't need to learn all the "fundamentals" first. That's my message.
Subscribe to:
Posts (Atom)