Other online diaries:
Mon, 25 Feb 2008
API design and error handling in code - 21:12
First it is true that putting in full error handling in code when using fairly standard libraries can take a lot of time, complexity and ugliness. However there should be some way somewhere to find out if errors happened I suggest, largely so you can deal with them if there is a situation they may be likely. Also understanding that libraries can fail in calls and what this means is important for coders, even if they do not handle them all. When marking assignments at uni I am keen to see that students have thought about error conditions and made the decision about what level of complexity to trade off against what likleyhood certain errors have of occurring.
The above issue with assignments however does tend to be students who are newer to programming than most free software hackers so there are considerations in both directions there. As for the other reason the above posts interest me, it is cool to see Cairo getting such props for great design again. Carl and co have done a stellar job with that library.
Thu, 01 Dec 2005
Open source cookie design attempt, what they missed - 17:44
Gladwell is a great author and often writes interesting and entertaining articles as I have noted in the past on occasion, however coming from an open source geek perspective there are obvious points missed here that show how the open source methodology could have been better applied. For example the quote "Linus Torvald, the Norwegian hacker" shows two problems, Linus' surname has an s, and Linus originates from Finland. The guy who ran this multi methodology project, Steve Gundrum, got off on the right foot, talking with Mitch Kapor as to the viability of applying the open source methodology to this new problem space, however I would suggest the team established did not operate in the manner teams on successful open source projects tend to.
They established a team for the open source group by inviting 15 well known specialists in the related food industry to be involved and make suggestions that would be implemented by Gundrum's company. Asking these people to design the cookie in effect. During the project, when some arguments or difficulties arose there was no dispute arbitration mechanism or established way to make a final decision. Also no one was actually elected as a benevolent dictator, without one or both of those mechanisms I am not surprised the project suffered and many people involved came out of it not particularly happy with the results.
Using the Linux kernel as an example again I think a few things they missed are, lack of benevolent leader, a dispute arbitration mechanism based on something akin to show me the code, ie coming up with ideas or suggestions is not sufficient, it needs to be implemented, tested and proven to work in a satisfactory manner, also some specific specialising in areas may have helped, especially with such a large team. Looking at the goals of the project and dividing up components such that people who may better work on those aspects could have more control over them. However I think one of the biggest failings was the scratch an itch component of free software or passion for it. This project though possibly interesting to those involved was unlikely to inspire passion from them. A combination of technical ability and the passion for the project really does provide a lot of the groundwork for success in the open source world. Even those people paid full time to work on open source are generally still passionate about their work (Linus, Tridge, Rusty, Anton, etc).
The article does mention some of Joel Spolsky's (of Joel on Software) reservations about open source development, and admittedly they could be relevant, however they could also be disputed. The argument about lack of innovation and simply following the herd would be disputed I suggest by looking at the innovation happening in given problem spaces in open source. Some of the desktop software such as amaRok, f-spot or the gstreamer based Fluendo (admittedly this is a company, however it is open source development with Flumotion) are all doing things way ahead of and more interesting than other entries in that problem space worldwide. Sure there are problems that do not mix well with open source development, but a simple argument being made that there is no innovation in the open source would I think is quite narrow minded.
Looking at how close the open source cookie was in second place I suspect that with a better understanding of the methodology and applying it with a group of people that fit well to that mechanism would have somewhat improved results.
Tue, 01 Mar 2005
How many programmers can you fit in a telephone booth? - 19:06
Today Mikal commented "It's impossible to work in a cubicle." suggesting that offices really do help a programmer with their work. I should admit one of the reasons I really like working at a University is they give you an office, Michael has an office here also, as a PhD student, however he does not have one at work as a senior software engineer.
Anyway this all ties in in an interesting manner also to something Lars Wirzenius wrote about recently. Having just read an IBM paper from 1978, "IBM's Santa Teresa Laboratory -- Architectural design for program development" (google can display an html version if you wish), Lars commented on how much it sucks that employers do not seem to think about the environment for programmers as much today as they did then.
I admit it does seem to lack sense for software companies, that base their business on producing good software (well one would hope they do that, though many do not appear to make that a primary goal) would forgo this sort of office plan so often. Michael Davies and Michael Still (both of whom I know personally and respect) both seem to agree with the ideas presented in the IBM paper or by Joel, I wonder how many others agree?
Thu, 23 Dec 2004
Over designing standards - 22:55
Both these are relevant, both to standards design and simply to programming. Do not do premature design or try to design for features you imagine you may one day want to use. Extreme Programming though of course simply another selection of tools in the programmers toolbox (and not the second coming as some people seem to think) does have some good points. One of which is the avoidance of premature design or coding for "future" features. The ACAP standards yesterday struck me as over engineered for a few basic things to attach to IMAP, using my example of the need for an address book that is accessible with your email. If an email client was to implement an address book functionality in ACAP, it would still need to decide on the format of the address book data in ACAP, and other clients would need to implement this and agree on this also.
Anyway back to the subject of conferences, Rory was covering the XML conference in an amusing manner, and at one point for example paid quite a lot of attention to the shoes worn by a speaker. The shoes a speaker wears are obviously important and must be blogged or covered in some way at conferences. For linux.conf.au we will obviously need to ensure there is online coverage of what shoes speakers are wearing. Mikal will I am sure be keen to self nominate for this task of telling the world about the speakers shoes, even uploading some photographs of their shoes maybe. Lets hope the speakers understand and do not become too freaked out by this behaviour.
Thu, 30 Sep 2004
Creative process of design - 18:06
Quoting from the entry
I just have to let the ideas percolate until my subconscious orders them, filtering it all into something better. This is how I've always done design, it just happens that Bradbury uncovered the mechanics of it for me. Forced design is why a lot of software is bad, that and all the compromise added to it. Well, there are probably other reasons commercial software sucks, like honesty and integrity, but that's not the point.