mult.ifario.us

People sometimes talk about a company having a "startup environment". This usually means less organizational structure and with that the perception of greater agility for the business, but at least to me, a relaxed organizational attitude is not the kernel of truth at the heart of a (successful) startup. A "startup environment" should indicate the presence of a single shared vision backed by clearly articulated, simple plans.

It's all too easy to start a company (or other endeavor) with "This idea is going to make me rich" as both motivation and success criterion, and it's possible to have that measuring stick rob you of all joy during the journey or lead you to make inappropriate decisions. I'd like to propose the promotional scratch-off -- the kind of gamepiece you get when you buy a fast food meal during a movie tie-in or something similar -- as a life lesson. (Life lessons for the price of a burger and coke are definitely among the most inexpensive available...)

You pay a fair price for a burger, and the gamepiece rides along as a bonus. Maybe you win fries, maybe a burger, maybe nothing... Even if you do win through persistence, eating burgers to win a prize is only going to make you fat.

I've been spending time on airplanes lately, so I'm slowly getting caught up on my weblog reading queue. I recently dequeued Paul Graham's note on hiring, and it reminds me of my advisor's metric -- whether a person has "bright eyes" (or not).

Assessing the brightness of someone's eyes has numerous advantages over degrees (which must be bought -- with tuition if nothing else -- and can be lied about), letters of recommendation (which are always guarded and almost always positive), references (which are selected to create a positive image), standardized test scores (which measure standardized capabilities), or other standard metrics; not the least of these is that it's an inclusive measurement as opposed to an exclusive measurement.

The downside of using ocular luminescence in hiring decisions is that it requires both talking and listening to candidates, so it's impossible to apply to a large applicant pool. It is a reasonable measure to apply to a small, pre-culled pool, but the probability is large that pre-processing already culled a number of bright-eyed candidates.

At least in my experience, bushy tails are irrelevant to hiring decisions...

I've been waiting for this for a while -- on 43 Folders today, a post about Act-On, a bundle for Mail.app that binds key sequences to rule actions. It's like a little slice of Quicksilver in Mail.app, so I'm one step closer to a mouse-free user experience. Even better, unlike AppleScript actions, Act-On has the property that a "move to folder" command correctly repositions the current message cursor.

While I was neither at the table nor a fly on the wall, I claim that the investment thesis for JBoss was straightforward -- Surely there's some way to make money on 30% marketshare. And while some of the analysis of IBM's purchase of GlueCode focuses on open source, I expect that the investment thesis was as simple and pragmatic as the one I imagine for the JBoss investment -- Surely there's some way to make money by using the Apache brand to drive business through the IBM services channel. (IBM already gives their software (a.k.a. "serviceware") away to drive the services channel, so it's not about free software.)

I have come to loathe .properties and .xml configuration files. (The use of them together is just inexcusable.) People tend to grab a properties or XML file when they need to parse something, and something is usually a configuration file of some stripe. This is convenient, as it happens that parsers for properties and XML files are readily available and built into Java, but both flunk on some aspects of usability:

• A configuration should be verifiable outside of the runtime container. I am deeply frustrated by compiling an application, building artifacts, and deploying those artifacts only to find out that a property was misnamed, a configuration file was not in the correct location, or a combination or parameters is unsupported.
• A configuration should be relatively easy to write. "Easy" in this context doesn't mean pretty colors and auto-completion, but it does mean that the configuration scheme should be human writable. (Human readable is a subordinate goal.) Overloading a markup language and thus forcing users to type everything twice doesn't count as "easy" and neither does overloading property naming for poor man's namespaces or hierarchy.

There are (at least) two viable alternatives:

• Use programmatic configuration. Build a reasonable, well-documented configuration API into your application and have users write to it.
• Invent a simple language and write a parser. It's not that difficult to pick up ANTLR or JavaCC and create a little language that meets your configuration requirements.

The use of a scripting language (like Beanshell or Groovy) can combine both approaches. (For example, Bob's approach for dynaop is a good example.)

I've only been to two of fifty. (It would be three, but the Gambero Rosso that I've been to is in Vernazza, not San Vincenzo.)