Double Barrel

Last Saturday marked the 15th homebrew competition in a friend's backyard, and as usual it was a lot of fun.  Last year I won the competition with a "Barack Obama Black Ale".  As that was my 4th consecutive win there was some talk at the judging table about asserting term limits.

This year we had a great turnout, 15 brews from maybe 10 brewers. I won "best name" for Double Barrel Palin Ail (puns intended).

The beer itself was only moderately popular (my other entry, "Red Head", did very well so far as actual beers went), but here is a recipe for the Palin Ail for those who might be interested, for a 5 US gallon batch:

• 8 oz 60L
• 6 oz Cara Munich
• 6 oz US Victory
• 2 oz Malto Dextrin
• 4 oz flaked rye
• Steeped 30 minutes at 150 F
• 6 lb light malt extract
• 1 lb dry malt extract
• Bittering: 1/2 oz Horizon 11.4 + 1 oz East Kent Golding 4.5
• Flavour: 3/4 oz East Kent Golding + 3/8 oz Nugget from my new hopyard
• Aroma: 1 oz East Kent Golding
• 3/4 tsp Irish Moss
• 1 tsp DAP
• Pitched a Nottingham dry yeast

Overbite in web pages

I'm probably dating myself when I remember (wistfully) the old Dr. Dobb's Journal slogan "Running light without overbite."  Certainly these days, in many parts of the high tech industry,  I don't see a lot of care and attention to load generated by this or that feature.

I returned to my desktop earlier this morning to find the fans cranked up and the cpu spinning at something like 50% load. I wasn't running anything in particular on the machine, no background compiles going on. No, I tracked this down to two web pages with some active content of some kind that I'd casually left open. The pages were: viewing an article on www.economist.com (about 15% cpu); and a friend's blog www.rklau.com/tins/ (bounces between 12-40% cpu).

Remember when 'engineer' was a verb?

en•gi•neer  vt  to contrive or plan out, usually with subtle skill or craft
en•gi•neer•ing  n  the application of science and mathematics by which the properties of matter and sources of energy are made useful to systems

Amusingly, when writing this note I visited ddj.com. It too loaded up a pile of crap, including a video with sound. Boy how DDJ has changed! And I guess (from the video) they don't see their apparent developer audience as populating cube farms.

switcher-backer

A guy I drink with from time to time recently posted that he finally switched to a Macbook Pro from a Thinkpad, and he's eating a little crow for all the times he's harassed his colleagues about their laptop choice.

Me, I switched a while ago, and while there are lots of things I like about the MacBook Pro, there are some things I hate.  Another drinking buddy of mine put it eloquently, the Mac is real pretty, but not ready for business.  I'm not sure I completely agree, but here are a few data points.

The Window resize handle. Singular. As in, one. You know, I want to use the shortest mouse gesture as I can to get to my window controls. Having just one resize handle in a corner, that's dumb. And it in the lower right corner, when I spend most of my time closer to the top left (eg, in a mail application, I'm selecting mailboxes and messages from lists on the left or top). Neither of these choices help usability at all, IMNSHO.

External monitors.  As a business user, I drag my laptop between my desk, with a big widescreen monitor; a meeting room, with a stupidly low-res projector; and my home, with something in between. Strange as this may seem, I don't close all my windows every time I plug into a new monitor.  That means my windows are already there, already as big as they are, and that single resize handle is off the bottom or edge of the screen so I can't reach it.

Application menus. Windows puts application menus in the window you are using, so they are close to hand. As if it weren't bad enough that the mac always has the menus at the top of the screen, here I am with two monitors. The window I'm working in is in one of them, meaning my mouse is in one of them. But all my application menus are in the other monitor. Short mouse gestures, remember?

Drop down selection lists.  My browser is in my nice big monitor, I start typing an address, and a drop down appears with matches against what I've typed so far. The drop-down is in the other monitor.

I could go on. Little frustrations, each of them, but add them up and its like the notion of two monitors and day-in-day-out use was something of an afterthought.

And while many folks blame PCs or Windows for flakiness with suspend and so forth, I've frankly found the MacBook to be worse. Every now and then mine just doesn't come back. Or it fails to suspend when I close the lid, and I take it out of my bag scorching hot.

Don't get me wrong, there are things I really like, too. I like having a shell prompt. I like the fact that a lot of Linux software runs. Heck, I ran linux exclusively on a laptop for about 4 years. I like Firefox on the Mac, which doesn't have the utterly brain-dead left-click-copy thing that firefox does on the PC and linux. Wireless networking is much better on MacBook. I like the magnetic power connector. I love love love the anti-glare screen, which I can use comfortably with full sunlight shining on it.

The thing that is an absolute killer, though, is gotomeeting. The fact that gotomeeting doesn't work on the mac makes it a bit of a non-starter. Either I'm carrying two laptops, or doing my remote presentations by remote desktop'ing to a windows box, which again is just dumb. This one isn't entirely Apple's fault, but a big issue nonetheless.

I'm sure the Mac is great as a desktop, or even as a laptop that you always use in a single configuration. But for a power laptop user, I don't think it is all there.

Is it better than a Windows laptop? On balance, not sure. 

I agree with Rick, though - it is very very pretty.

Tool for requirements management - not

I was at an industry talk a week or two ago, and a vendor in the corridor was selling a Requirements Management tool.

The tool in question provided a mechanism to enter, store, and report on product requests. It also allowed web entry of requests directly by customers and prospects via a portal, so the busy PM wouldn't have to enter requests himself. So far as I could tell, or the demo boy could tell me, it didn't do much else.

In the simplest form, requirements management could be just storing and listing requests. I guess. Though that's pretty simple-minded.

An axiom for product managers is that we serve markets, not individuals. We build product that meets the needs of a broad audience. We don't like to build one-offs. We identify groups of people with similar needs in terms of features, delivery channel and so forth, and money to spend, and then go about fulfilling those needs.

So for a product request to be useful to a product definition process, we need to be able to do things with it that are a little more involved than just listing. We may need to decompose into finer grained components of ideas. We definitely need to combine several requests together that may be worded in different ways. We want to identify the group who made that request, and collect the other requests made by group.  We probably want to define one or more product features that together satisfy that request, and associate releases with those product features. And so forth.

Capturing, keyword search, and listing are just the barest beginnings, and without the analysis capability are effort for no return. After all, I can capture requests just fine in an email folder.

These thoughts in mind, I asked the demo boy a few simple questions about how his tool would help categorize requests, or trace request (de)composition, or basically support any kind of decision making.  He earnestly answered the third question, "Sure, you can do that with our tool! If you see a request come up 2 or 3 times, you probably want to build it in your next sprint."

*sigh*