Projects vs Business

I read something via reddit recently that hit a nerve:

In this article: Meeting the founders of reddit

he says that: “Reddit, like many other initiatives is more a “project” than a “company/business”

Like everyone, I get inspired by Paul Graham’s writings, and like the idea of making money doing something cool, but my brain seems to be much better at generating ideas for fun projects/cool hacks, as opposed to businesses. I wonder if it’s possible or worth it to make that change. Sometimes trying to “be what you aren’t” is unpleasant and unsuccessful. On the other hand, perhaps it’s more of an acquired skill that doesn’t really conflict with the ‘hacker’ mentality…

Agile methods for introducing Agile Development?

Something else I found on reddit:

An Agile Approach to a Legacy System (pdf)

seems interesting because it deals with crappy, real world code, rather than some ideal workplace that exists only in fantasyland. I wish that they’d explained a bit more, at the technical level, of how they managed to integrate their new system with the old one, as that is often a difficult task when the code always has to be up and running, and the old system is in production.

I have a Big Ball of Mud to deal with myself, and a development process that is not agile, nor much of anything else really. It’s the kind of situation that is only going to change ‘in small iterations’, rather than trying (and quite possibly failing) to impose a new way of doing things in one fell swoop. So perhaps what I need is an agile methodology for introduction agile development in small iterations?

Hecl

I released a new snapshot of Hecl this evening, with a few minor fixes. I’m pleased that the project has picked up a regular contributor, Wolfgang Kechel, who seems to be doing some interesting things with it. He’s a bright guy, and it’s good to have feedback and someone to talk things over with. I have been sidetracked with Ruby on Rails (more on that in the future) lately, so I haven’t dedicated as much time to Hecl as I would have liked to.

Oregon

I found this brochure about open source in Oregon. It’s “marketing materials” kind of stuff, but still… I’m proud to see all the interest in open source in my home state. Almost makes me want to go back, but then I talked with my parents on the phone, who told me about the 24 days of rain in a row, which brought me back to my senses.

OFBiz

I had been investigating OFBiz as something to use in the company where I’m working, but apparently that’s not going to happen for now, which is a pity, because it’s well done software, and more importantly, has attracted a bright, diverse group of people to work on it. Indeed, I liked it so much that I’m helping out (I hope!) by acting as a “mentor” for the project as it goes through the process known as incubation at the Apache Software Foundation, which means that it hasn’t officially been accepted as part of the ASF, but has the potential to do so if we get all the i’s dotted and t’s crossed. It’s been an interesting experience, as it’s about as far away as you can get from my Tcl work at Apache!

Whilst ambling around on the web after seeing a post on reddit.com that piqued my curiousity, I happened on some work discussing “maximizers and satisficers”, which, put crudely, says that there are two kinds of people. Those who, out of a group of options want the best one – maximizers – and those who just want something that will work – satisficers.

Anyone who has been around programming languages more than, say, a week, will instantly recognize the above theme in the endless discussions of “which programming language is best?”, or more generally, which “X” is best? I’d be willing to bet that programmers, and especially open source programmers, tend towards the ‘maximizers’ end of the spectrum – I don’t want just any old X, I want the best one, dammit! Sometimes, this can be a good thing, as it leads us to continuously seek to improve things we come into contact with, or try new approaches, it can also be detrimental if your goal is simply to accomplish some task, rather than spending too much time fretting about finding the perfect tools to accomplish the task with.

This also has ramifications for people designing or dealing with programming languages. One of the papers (the original?) on the subject (here), actually deals with the fact that maximizers, in their search for perfection tend to be less happy. Where satisficers are happy because they’ve got something that works, and they can go on to something else, maximizers have lots of room for “fear, uncertainty, and doubt” about their choices.

In some instances, actually reducing people’s choices makes them happier. Python’s “one good way to do it” makes everyone happy, because both maximizers and satisficers know that they’re doing things right, and don’t have room to worry. Another example that I know well from my involvement in the Tcl community is “object systems for Tcl”. For those who don’t know Tcl well, it’s an extremely flexible, extensible language, both in the language itself and in terms of its C API. So flexible, in fact, that you can write an OO system in Tcl itself, which has been done, or in C, which has also been done several times, leading to a proliferation of OO systems, and a never-ending stream of questions on the newsgroup about which is the best one? Perl’s “there’s more than one way to do it”, despite apparently providing and pushing choice, may actually work well because it encourages people to be satisficers and use whatever works. I’m sure everyone can think of examples where too much choice causes doubts and hesitation.

I think the lesson to be learned is that while it’s important to encourage experimentation in order to explore possible solutions to problems, at a certain point it makes sense to consolidate and provide one or two recommended ways of doing something. That’s not always possible (Linux distributions, for instance), and squashing competing ideas too early might cause friction with people generating innovation, so it can be difficult to accomplish, but I believe it’s an important social aspect of software creation to keep in mind.

We’ve hit something of a stumbling block with Hecl, and it’s proving tricky. Far from being “write once run anywhere”, Java has many versions, when you take into considerations the wide array of devices that run one of several configurations roughly lumped together as “J2ME”. My cell phone’s implementation doesn’t have floats, for instance. This necessitates that the J2ME and J2SE versions contain different code, but Java doesn’t make this easy, because there are no macros or other ways of conditionally compiling code.

The solution we’ve adapted so far is problematic because it’s not very fine grained: we have two separate directories, one for ‘core’ Hecl (sans floats) and another that contains the exact same classes, but with floating point. For instance:

BasicMathCmd.java – no floating point

BasicMathCmd.java – the floating point version.

As you can imagine, this means that code is replicated in two places, and each change has to be done twice, carefully, keeping track of the actual differences between the two files. This can only get worse as the code grows.

I’ve seen some hacky ways of doing macros and things like that, but they don’t look very satisfying. I’m too much of a Java novice to think of anything better than what we’ve got, though.

Update 2006-04-20: we chose to use Antenna

Bill Gates wrote his famous letter thirty years ago, tomorrow:

http://www.blinkenlights.com/classiccmp/gateswhine.html

In the meantime, people are still missappropriating software, the “hobbyists” have returned with a vengeance and have built software that rivals or bests Mr. Gates’, and the economics of the industry still aren’t entirely clear. What economist would have ever predicted the success of Open Source? They’re certainly fascinated by it now that it’s here.