June 28, 2007
Inspired by a post on Coding Horror I’m dropping advertisements here.
“I am no fan of advertising. I hate the fact that most websites are plastered with obnoxious, barely relevant ads. I’ve considered advertising before, but I rejected it. I don’t want to be part of the problem.”
I too hate the fact that most websites are plastered with barely relevant ads. Until now I have never seen myself as part of the problem because I only use one block of light Adsense ads in the sidebar, not several blocks everywhere. But the post opened my eyes and I now can see myself as part of the problem.
So I’ll drop ads here.
Perhaps ads will come back sometimes in the future, when I have to live from them or I can support other open source developers. Until then, no ads.
Paul Graham is a funny guy. From one point in history, where he wrote an unmaintainable (they had to drop it) and unsuccessfull (Amazon has beaten them) piece of software which he sold to someone clueless (Yahoo will go down in flames) with too much money (they again buy companies without clue), he extrapolates (from this random event) his view to the whole craft of software development. Funny to read, but pointless. If you read Paul Graham, Nostradamus might be a good reading for you too.
Especially when reading his ramblings about painters, one gets the impression that it depends on the tool an artist uses whether the art he creates is good or bad. Oil is good, crayons are bad. Somehow then he applies this to software development. Funny! I’ve seen good code in Basic, Ruby, Lisp, Machine Code, Java, C and a dozen other languages. And I’ve seen bad code in Basic, Ruby, Lisp, Machine Code, Java C and a dozen other languages. And I’ve seen good and bad developers writing code in Basic, Ruby, Lisp, Machine Code, Java, C and a dozen other languages. In reality good code usually depends on the production enviroment and the skills of the developer. Not on the tools (Which does not mean you should not choose adequate tools).
A worthy goal for life would be to comment every blog post about Paul Graham with a link to Fooled by Randomness (No there is no partner link because I want to make money from your quest for knowledge) and a link to Hacknots faery tales.
June 27, 2007
Just to let you know: Since my departure from my old employer three months ago I’ve tried to get the Radeox rights for further development through several different channels. But no final decision from any channel. As it currently looks I won’t get the rights for future developements which is quite sad. I will still try till the end of June and then see what other paths are open to me. Do people still want to use Radeox?
June 22, 2007
The biggest problem with tales about software success is that they only show the survivors. This problem is independent of the domain, be it Rails, Scrum or CMMI success stories. Survivor bias is when you only look at the survivors of a process and then attribute the success of the survivors to some attributes like cleverness or strongness. Survivor bias is most easily shown with financial funds. Say you want to examine the success of some financial funds. You look at funds which are investing in high tech stocks. When looking at nine funds with the growth rates of 7.3, 9.2, 12.1, 5.4, 6.7, 7.2, 10.1, 8.5, 8.8 we get an average rate of 8.4 percent. This finding would suggest that funds which invest in high tech stocks have an average growth rate of 8.4. But assume there was one fund which defaulted. People looking at average growth usually only look backwards, which means they only select surviving fonds. When we go back in time and look toward the future, we see ten funds we want to measure. After some years, nine have survived and one has defaulted. So from a point back in time we selected ten funds, not nine. And with the tenth fund, with a growth rate of -100%, included in the average we get an average growth rate of -2.5 percent for the ten funds compared to 8.4 percent for the nine surving funds. That’s survivor bias.
The same can be said about other processes, most notably progessing of CEOs and companies, especially start ups. When looking at successfull startups people are mislead to attribute the success of a startup to some genius founder, good products or other attributes when in fact, an equally good explaination is that the startups had only luck (for that we need to get back in time and look into the future with all the startups, not look back from the point of successful startups). The same goes for CEOs: most could be successfull by luck, the unlucky ones just get kicked out faster and don’t show up as often as lucky ones.
Coming back to software development. We hear lots of success stories from companies and developers about tools, languages, frameworks, plattforms and processes. Those people praise Rails, Scrum or CMMI. But looking at funds and transfering our knowledge to those praise stories, we could assume that those involved were just lucky. Companies which failed with Rails, or Scrum, or CMMI and the countless other solutions for software development seldom talk about their experiences. Companies which fail with Scrum just drop it. Companies who try Rails in a pilot just don’t use it. Companies who are not able to get their CMMI certification just don’t start it. And some of the companies even didn’t survive to tell their tale. Most people publish success stories on their blogs, in magazines or on websites because people want to read success stories and success stories make the authors look good. Failures make them look bad. This leads to survivor and publish bias.
Next time you hear a success story, think about all the people who don’t or couldn’t tell tales about their failures. The success might just be plain luck and survivor bias.
June 21, 2007
There is a lot of discussion about concise code. Comparing Java to Ruby, obviously Ruby has more concise code (This article contains code examples, which could be written better and which experienced Java and Ruby developers would write in differently. But the examples were chosen to illustrate points).
Compare this Ruby code taken from the Pragmatic book
songType = if song.mp3Type == MP3::Jazz
if song.written < Date.new(1935, 1, 1)
Song::TradJazz
else
Song::Jazz
end
else
Song::Other
end
with the corresponding Java code:
public SongType getType(Song song) {
if (song.isMp3Type(Mp3Jazz.class) {
if (song.isWrittenBefore(new Date(1,1,1935)) {
return SongType.TRAD_JAZZ;
} else {
return SongType.JAZZ
}
} else {
return SongType.OTHER;
}
}
Java has more code than Ruby in this example, but the cyclomatic complexity is the same for both examples. Although the size of the Ruby example could be reduced, in this version the LOC is also the same. You can’t reduce the CC with choosing another language, only by choosing another algorithm or language paradigm.
When adding comments to the code examples like this
/**
* Gets the song type from a song. This does not
* return the mp3 type information from the song
* but tries to determine the song type from the mp3 type,
* time period and other enviroment variables
*
* @param song the song which should be checked
* @return the song type for the song
*/
public SongType getType(Song song);
or like this for a dynamic-reference-typed language:
/**
* Gets the song type from a song. This does not
* return the mp3 type information from the song
* but tries to determine the song type from the mp3 type,
* time period and other enviroment variables
*
* @param {Song} song the song which should be checked
* @return {SongType} the song type for the song
*/
def type(song) ...
The difference between the two language styles dimish and the CC [1] to understand the code for a developer which has never seen the method is the same. In his head he has to order and solve the nested if statements to come to an understanding of what the method does. He might parse the Ruby example faster, because it’s more concise, but the understanding part after the mental parsing is the same. Current studies show though that people don’t read and parse text word by word but detect meaning by looking at patterns of word beginnings and endings. This would suggest that less code doesn’t increase parsing speed a lot.
If conciseness of code is the deciding factor for faster understanding written code, then languages like K should be instant (some K programmers claim to instantly understand code by seeing it). A Hilbert matrix [2] in K [3] looks like this:
{1%(!x)+\:1+!y}
The Java example from before can be written more understandable, for example with the Hamcrest library. This code is even less concise, but easier to understand
public SongType getSongType(Song song) {
if (is(song.getMp3Type, equalTo(Mp3Jazz.class)) {
if (is(song.written(), before(1,1,1935)) {
return SongType.TRAD_JAZZ;
} else {
return SongType.JAZZ
}
} else {
return SongType.OTHER;
}
}
It would be very interesting to see studies which compare code styles, conciseness and cyclomatic complexity and how they releate tounderstanding code which you haven’t written. Because as Robert Glass writes in the excellent facts and fallacies of software engineering: “Fact: Maintenance is the most important life cycle phase with 40-80% of the cost.” I have currently the feeling that most language innovation happens with rapid development, not low maintainance.
[1] http://www.fromthetrench.com/category/cyclomatic-complexity/
[2] http://en.wikipedia.org/wiki/Hilbert_matrix
[3] http://www.langreiter.com/space/k-notes
June 19, 2007
I thought about open source and had lots of discussion in the past few years about open source in general, business models, different and superiour licenses, pragmatic open source and stuff. As I’ve been also developing open source software for the last twenty years, I’m interested in the state of the open source developers.
Some studies have shown, that half or two thirds of open source developers come from Europe (with South America and Asia growing strong). Compare that with the image that open source is a North American phenomenon[*]. In the mind of Europeans and especially European politicians open source has not the importance it should have based on the influence Europe has on open source through it’s developers. What about founding an European Open Source Society? For exchanging ideas, moving open source to the future and lobbying politicians to pay more attention to open source, the economic impact, the social impact and the chances there are for Europe to play an important role in open source. Sounds good to me.
What about founding one?
[*] Perhaps because more loud open source advocate live or move to the US and more companies in the US monetize open source projects
June 17, 2007
After fiddling around with the security framework Gabriel I wrote some time back and which I need for Reposita. I thought about combining Gabriel with Google Guice for fun. The only problem was that Gabriel can be used with interceptors to protect methods. How could I get them working with Guice?
I was using Dynaop, the best aop framework for Java, which I wrote a Spring bean factory for to use with Gabriel. For Guice I tried to port it when Bob told me that Guice already supports interceptors :-) So using my AOP alliance interceptors from Gabriel with Guice was a no brainer. Everything worked as excpected. Guice is great.
So protecting methods with annotations is easy now with Gabriel:
public interface SecureObject {
@NeedsPermission("SET_NAME")
public void setName(String name);
}
Two things I’m still thinking about are what to call the annotation ? NeedsPermission, Permission, WithPermission? And to get the interface method I currently iterate over all interfaces of the class, any ideas how to do that faster?
Otherwise: http://gabriel.reposita.org/