Wide Awake Developers

Perfection Is Not Always Required

| Comments

In my series on dirty data, I made the argument that sometimes incomplete, inaccurate, or inconsistent data was OK. In fact, not only is it OK, but it can be an advantage.

There’s a really slick Ruby library called WhatLanguage that illustrates this beautifully. The author also wrote a nice article introducing the library. WhatLanguage automatically determines the language that a piece of text is written in.

For example (from the article)

require 'whatlanguage'

"Je suis un homme".language # => :french

Very nice.

WhatLanguage works by comparing words in the input text to a data structure that can tell you whether a word exists in the corpus. There’s the catch, though. It can return a false positive! That would mean you get an incorrect "yes" sometimes for words that aren’t in the language in question. On the other hand, it’s guaranteed against false negatives.

You might imagine that there are pretty limited circumstances when you’d use a data structure that sometimes returns incorrect answers. (There is a calculable probability of a false positive. It never reaches zero.) It works for WhatLanguage, though.

You see, each word contributes to a histogram binned by possible language. Ultimately, one language "wins", based on whichever has the most entries in the histogram. False positives may contribute an extra point to incorrect languages, but the correct language will pretty much always emerge from the noise, provided there’s enough source text to work from.

So, there’s another example of information emerging from noisy inputs, just as long as there’s enough of it.

 

 

Arrival at JAOO

| Comments

Considering that it’s 7:30 AM local time—where "local" means Aarhus, Denmark—and I’m awake and online, it looks like I’ve successfully reset my internal clock.  Of course, my approach consisted of staying awake for 28 hours continuously then having three excellent beers with dinner.  There are probably easier ways, and there may be repercussions later.

I’ve always heard good things about JAOO, so it was an honor and a delight to be invited. So far, just hanging around the hotel has been interesting. Waiting to check in yesterday evening, I encountered Richard Gabriel and one of the guys who designed Windows PowerShell. (He still calls it Monad, which I think was a much better name than "PowerShell".  Also, I wish I’d gotten his name, but I was a too distracted by the problem with my reservation.)

After dinner, I started chatting with some ThoughtWorkers over a game of ZombieFluxx. Two observations: first, ZombieFluxx is the kind of game that only a computer programmer or a lawyer could love. The deck of cards includes many cards that change the rules of the game itself. Gameplay changes from turn to turn based on the current state of the rule cards showing. There’s even a card that requires you to groan like the undead whenever you turn over a new "zombie" card. Very meta.  Second, it seems that TW people make up half of every conference I go to. They must have a fantastic training budget, because they are disproportionately represented relative to their much larger competitors like Accenture, Deloitte, and that crowd. Woe to the conference industry if ThoughtWorks falls on hard times.

My primary goal for today was to get over jetlag. Having accomplished that before 8 AM, I’ll now see about straightening out my hotel situation. It’s hard to think much about software when you may not have a roof over your head come nightfall.

Update: Got my hotel issues resolved. Now at a thoroughly modern, thoroughly Danish hotel called the "Best Western Oasia". Funny, but I always think of "Best Western" as the cruddy, mildewed cheap hotels off the Interstate in places like west Texas and Birmingham, Alabama. This hotel may cause me to reevaluate that image! It’s nice, in a kind of "living inside Ikea" way.

(And, yes, I know Ikea is Swedish, not Danish. It’s the bare wood, spare furnishings, and black lacquer I’m talking about.)

The Infamous Seinfeld-Gates Ad

| Comments

The Seinfeld/Gates ad is so laughably bad that people are already building indexes of the negative reactions, less than 24 hours after it launched.

I have my own take on it.

Gates is the most recognizable geek on the planet. For most non-techies, he is the archetype of geekhood.

What kind of name recognition does Steve Ballmer have?  Outside of developers, developers, developers, and developers.  Would a silver-haired manager ever use him for a cheesy business analogy in a meeting?  Nope. Blank looks all around.  Tiger Woods and Bill Gates make good metaphors. Steve Ballmer doesn’t.

Ray Ozzie? Not a chance. Even most techies don’t know who Ozzie is.

This commercial wasn’t about churros, The Conquistador, or briefs riding up. It was all about one line.

"Brain meld".

It slipped by fast, but that was it. That was the line where billg@microsoft.com began the public torch-passing ceremony.

A couple more spots, and we’ll see either Ballmer or Ozzie entering the plot. Then we get the handoff, where John Q. Public is now meant to understand, "OK, Bill Gates has retired, but he’s passed his wireframe glasses and nervous tics on to this guy."

Seriously, it’s torch-passing.  Don’t believe me? You will when you see Ballmer air-running past a giant BSOD in the final ad.

In Korean

| Comments

"Release It" has now been translated into Korean. I just received three copies of a work that’s hauntingly familiar, but totally opaque to me.

I kind of wonder how the pop-culture jokes came through.  I bet C3PO and R2D2 made it OK, but I wonder whether "dodge, duck, dip, dive, and dodge" made it past the Korean copy editor.  (For that matter, I’m faintly surprised it made it past the English copy editor.)

97 Things Every Software Architect Should Know

| Comments

O’Reilly is creating a new line of "community-authored" books. One of them is called "97 Thing Every Software Architect Should Know".

All of the "97 Things" books will be created by wiki, with the best entries being selected from all the wiki contributions.

I’ve contributed several axioms that have been selected for the book:

Long-time readers of this blog may recognize some of these themes.

You can see the whole wiki here.

 

How Buildings Learn

| Comments

Stewart Brand’s famous book How Buildings Learn has been on my reading queue for a while, possibly a few years. Now that I’ve begun reading it, I wish I had gotten it sooner. Listen to this:

The finished-looking model and visually obsessive renderings dominate the let’s-do-it meeting, so that shallow guesses are frozen as deep decisions. All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed.

Wow. It’s hard to tell what industry he’s talking about there. It could easily apply to software development. No wonder Brand is so well-regarded in the Agile community!

Another wonderful parallel is between what Brand calls "Low Road" and "High Road" buildings. A Low Road building is one that is flexible, cheap, and easy to modify. It’s hackable. Lofts, garages, old factory floors, warehouses, and so on. Each new owner can gut and modify it without qualms. A building where you can drill holes through the walls, run your own cabling, and rip out every interior wall is a Low Road building.

High Road buildings evolve gradually over time, through persistent care and love. There doesn’t necessarily have to be a consistent–or even coherent–vision, but each own does need to feel a strong sense of preservation. High Road buildings become monuments, but they aren’t made that way. They just evolve in that direction as each generation adds their own character.

Then there are the buildings that aren’t High or Low Road. Too static to be Low Road, but not valued enough to be High Road. Resistant to change, bureaucratic in management. Diffuse responsibility produces static (i.e., dead) buildings. Deliberately setting out to design a work of art, paradoxically, prevents you from creating a living, livable building.

Again, I see some clear parallels to software architecture here. On the one hand, we’ve got Low Road architecture. Easy to glue together, easy to rip apart. Nobody gets bent out of shape if you blow up a hodge-podge of shoestring batch jobs and quick-and-dirty web apps. CGI scripts written in perl are classic Low Road architecture. It doesn’t mean they’re bad, but they’re probably not going to go a long time without being changed in some massive ways.

High Road architecture would express a conservativism that we don’t often see. High Road is not "big" architecture. Rather, High Road means cohesive systems lovingly tended. Emacs strikes me as a good example of High Road architecture. Yes, it’s accumulated a lot of bits and oddments over the years, but it’s quite conservative in its architecture.

Enterprise SOA projects, to me, seem like dead buildings. They’re overspecified and too focused on the moment of rollout. They’re the grand facades with leaky roofs. They’re the corporate office buildings that get gerrymandered into paralysis. They preach change, but produce stasis.

Dan Pritchett on Availability

| Comments

Dan Pritchett is a man after my own heart. His latest post talks about the path to availability enlightenment. The obvious path–reliable components and vendor-supported commercial software–leads only to tears.

You can begin on the path to enlightenment when you set aside dreams of perfect software running on perfect hardware, talking over perfect networks. Instead, embrace the reality of fallible components. Don’t design around them, design for them.

How do you design for failure-prone components? That’s what most of Release It! is all about.

Agile Tool Vendors

| Comments

There seems to be something inherently contradictory about "Enterprise" agile tool vendors. There’s never been a tool invented that’s as flexible in use or process as the 3x5 card. No matter what, any tool must embed some notion of a process, or at least a meta-process.

I’ve looked at several of the "agile lifecycle management" and "agile project management" tools this week. To me, they all look exactly like regular project management tools. They just have some different terminology and ajax-y web interfaces.

Vendors listen: just because you’ve got a drag-and-drop rectangle on a web page doesn’t make it agile!

The point of agile tools isn’t to move cards around the board in ever-cooler ways. It isn’t to automatically generate burndown graphs and publish them for management.

The point of agile tools is this: at any time, the team can choose to rip up the pavement and do it differently next iteration.

What happens once you’ve paid a bunch of money for some enterprise lifecycle management tool from one of these outfits? (Name them and they appear; so I won’t.) Investment requires use. Once you’ve paid for something—or once your boss has paid for it—you’ll be stuck using it.

Now look, I’m not against tools. I use them as force multipliers all the time. I just don’t want to get stuck with some albatross of a PLM, ALM, LFCM, or LEM, just because we paid a gob of money for it.

The only agile tools I want are those I can throw away without qualm when the team decides it doesn’t fit any more. If the team cannot change its own processes and tools, then it cannot adapt to the things it learns. If it cannot adapt, it isn’t agile. Period.

Beyond the Village

| Comments

As an organization scales up, it must navigate several transitions. If it fails to make these transitions well, it will stall out or disappear.

One of them happens when the company grows larger than "village-sized". In a village of about 150 people or less, it’s possible for you to know everyone else. Larger than that, and you need some kind of secondary structures, because personal relationships don’t reach from every person to every other person. Not coincidentally, this is also the size where you see startups introducing mid-level management.

There are other factors that can bring this on sooner. If the company is split into several locations, people at one location will lose track of those in other locations. Likewise, if the company is split into different practice areas or functional groups, those groups will tend to become separate villages on their own. In either case, the village transition will happen sooner than 150.

It’s a tough transition, because it takes the company from a flat, familial structure to a hierarchical one. That implicitly moves the axis of status from pure merit to positional. Low-numbered employees may find themselves suddenly reporting to a newcomer with no historical context. It shouldn’t come as a surprise when long-time employees start leaving, but somehow the founders never expect it.

This is also when the founders start to lose touch with day-to-day execution. They need to recognize that they will never again know every employee by name, family, skills, and goals. Beyond village size, the founders have to be professional managers. Of course, this may also be when the board (if there is one) brings in some professional managers. It shouldn’t come as a surprise when founders start getting replaced, but somehow they never expect it.