The Need for Leeway:

By bending the rules we’re not violating fairness. The equal and blind application of rules is a bureaucracy’s idea of fairness. Judiciously granting leeway is what fairness is all about. Fairness comes in dealing with the exceptions….

That’s why in the analog world we have a variety of judges, arbiters, and referees to settle issues fairly when smudgy reality outstrips clear rules….

Matters are different in the digital world. Bits are all edges. Nothing is continuous. Everything is precise. Bits are uniform so no exceptions are required, no leeway is permitted.

From the Drug News Desk:

“The absurdity of its illegality has been clear to me for some time. I learned about pot from my kids and realized it was a lot better than Scotch, and I loved the Scotch.”

JP adds, “He’s the former CEO of Progressive; he’s been described as a ‘functional-pot head.’

The McMurphy Nietzsche:

There can be little doubt of how Nietzsche would have been managed by psychiatrists of today. He would have been diagnosed with manic depressive psychosis (current terminology uses the less meaningful term bipolar disease). He would have been loaded with drugs from the armamentarium of psychotropic medications, which no doubt would have suppressed some of the more bizarre symptoms that he displayed during his fourteen months of institutionalization. If, in spite of medications, Nietzsche continued to show signs of psychosis, his diagnosis would have been changed to chronic schizophrenia, a common switch in long term manifestations of psychosis. In either case, Nietzsche’s unique creative life would have come to an end, as it did in the actual course of his illness.

Scott Adams on "Incentives":

It is always the dream of corporations to give people things that seem like money to people without giving them any actual money. In the dot-com era, we had stock options. Now we don’t have that option anymore. More and more companies are giving rocks. They are actually paperweights that say “quality” or have some other inspirational message. They are morale building mementos that by any other definition are in fact rocks. Companies are telling people they are not getting a raise and then are handing them a blunt object. I’m surprised there hasn’t been more trouble

Link found at Cafe au Lait.

Rothko…on API Design

“We favor the simple expression of the complex thought. We are for the large shape because it has the impact of the unequivocal. We are for flat forms because they destroy illusion and reveal truth.”

Mark Rothko

Though the quote comes from an artist, it seems like good advice for coding as well.

Wunderkammer.org, or Monthly Blog Navel Gazing Post

Though I’ve collapsed my posting activity — sparse as it’s been recently — to just this weblog, I keep finding myself wanting to use the old bookmark weblog again and again. So, why the hell not?

I don’t think any one actually looked at it, but, if you’re really starved for content, I post links, like things to read later, there pretty often. They’re usually technical, but sometimes they’re just small quotes and little things that I don’t feel are polished enough even for the low standards I try to maintain over her.

A Whiff of Isle

I think about once every 3 months, all the sudden, I just get flavor deja vu of Isle scotches, like Laphroaig, in my nose and mouth. I’m just sitting there, then all the sudden, all I can taste and smell is scotch.

Hopefully, this doesn’t mean something terrible.

Stupid Typos

while (methodsItr.hasNext()); {
    JavaMethod method = (JavaMethod)methodsItr.next();
    methodsMap.put(makeMethodSignature(method), method);
}

See ifin’ you can spot the “problem.”

More Action on the CBLT HFSC

“Following their worthless meeting, John Holt will call a company meeting and act liking Caesar will proclaim the establishment of Cobalt-India, where software development will take place.”

And for the FX-folk,
there’s a lil’ sumthin’ on the FX HFSC
. Also, the FX exec page is finally updated,
and there’s a press release of the recent news. No matter what you think, it’s
a little weird not seeing JB’s fote up there.

Food, Work, and Drink


duct tape removes warts.

(1.) Apparently, in 5 years, only the Greeks can make Feta.

(2.) Martin Hutchinson on the Future of Work, Rudolph the Red-Nosed Reindeer:

An ability to handle rapid change will no longer be necessary, or even desirable…. The ability to work 80-hour weeks will also be superfluous. Whereas tech-savvy staff was scarce in the boom years, they will be plentiful once growth and change have vanished. In some areas, similar to automobiles or movies in the 1930s, innovation will continue, since it will form an important competitive weapon by which strong companies will increase market share at the expense of the weak.

(3.) And, finally, here’s a drink that’s, well, just not good. However, Stolichnaya + half a lime = yuh!

Preventative Alibi

“There are many who find a good alibi far more attractive than an achievement. For an achievement does not settle anything permanently. We still have to prove our worth anew each day: we have to prove that we are as good today as we were yesterday. But when we have a valid alibi for not achieving anything we are fixed, so to speak, for life. Moreover, when we have an alibi for not writing a book, painting a picture, and so on, we have an alibi for not writing the greatest book and not painting the greatest picture. Small wonder that the effort expended and the punishment endured in obtaining a good alibi often exceed the effort and grief requisite for the attainment of a most marked achievement.”

Eric Hoffer

Review Before Checkin

The big problem with code review before checkin, is that the developer has already done their unit tests: To the best of their knowledge, there are no bugs in the code. So they have little motivation to change it just to improve some abstract concept, like some other person’s idea of “quality.” Making further changes means they’ll have to do the manual testing half of the work again, because they might introduce bugs, and this ain’t no fun.

Jeff Grigg

We review code before checking it in at work, and I’ve yet to figure out if it’s better to do or not to do. On the positive side, there’s a great chance to catch tons of bugs and enforce styles and best practices; on the other hand, it can slow down checking in code, and even discourage changes.

The Good

The best effect of reviewing code before checking it in that I’ve encountered comes from having to explain, out loud, your code to someone else. Explaining the code out loud moves the ideas of the code from the muddy, somewhat vague, world of your head into a much cleaner, more explicit, description. So far I’ve found that the easier code is to explain, the closer to the simplest solution it is.

Also, in talking through the code, I not only improve the skill itself, but I can test out new jargon and mental frameworks for thinking about code.

Ultimately, these things could be had by even light pair programming, or just having developers sharing the same workspace. But, I’m starting to sway towards liking having my own office.

The Bad

The largest problem that I’ve encountered is a slowing down of collaboration: while developing a chunk of code, the parties collaborating want to access and use each other’s code as it’s being developed. The standards for passing a code review are usually higher than the state the code is in as it’s being developed.

One solution, might be to allow coders to create their own branches in the version control system to work in. The coders can check in all the code they want and, more importantly, share that checked in code with others. When the code is done, the developer’s branch could be reviewed, and merged back into mainline. This might be a tad too heavy though, esp. with the often clunky nature of version control systems.

And, of course, if the people reviewing code aren’t allocated enough time, getting reviewed can be quite a slow down. This begs the (open) question about who you “certify” to review code, or if you even “certify” people in the first place. At first, it seems like you don’t want everyone to be able to review code, as that might make reviewing meaningless. But, without enough reviewers, the Review Slow Down tends to occur. There’s probably some ratio of reviewers to people in your group that could be discovered; maybe hunting down that little number would alleviate any slow down problems.

Late night Links: Content for the Sake of Content?

Just in from the monkey wire:
“In a bizarre incident, a monkey tore off a soccer coach’s ear while he was trying to save his young trainees from the simian at a stadium here.”

Friends of Thomas Paine “After his return to America in 1802, Paine came under constant assault by evangelical Christians for his deist writings.”

“I hate being lost and late. Now if I’m lost, and I got plenty of time…. So what! The other thing is, I can’t stand it when people mess with my stuff. The third thing I can’t stand, is meeting new people. I got no problem meetin’ strange dogs. Bring those doggies on!” –Letterman

FundsXpress Raises $10 Mil Names Warrington CEO:

FundsXpress Financial Network, Inc., a provider of online financial services, received $5 million as part of an overall $10 million equity financing plan from Warburg Pincus and The Texas Growth Fund. At the same time, the company named Brent Warrington as chief executive officer. This investment allows FundsXpress to continue to expand its customer base, explore new partnerships and add new products and services to support its client base. John Burns, founder and former chief executive officer will serve as vice-chairman of the board of directors.

Thanks to Matt Ray for sending it along to TheLoC. Also, the same story, from The Austin Business Journal

Can I Use the Word "Agile" Enough?

Zane’s post on the negative effects of personal motivations on software development reminded me of Cockburn’s discusion in Agile Development on the same topic. I went a-Googling for a write up, or summary of what was in the book. The closest thing I found was this, but the rest seemed like slim pickins.

However, as always, there are other fun things to look at later:

Artificial Constraints

What we fear is that current
methods do not allow us to build soft enough software, because present methods and
design paradigms seem to inhibit adaptability. Therefore the majority of software
practitioners tend to become experts at what they can specify in advance, working with
the unstated belief that there exists an optimal solution that can be planned a priori.

Once technology is adopted by an organization, it often becomes a constraining structure
that in part shapes the action space of the user.

–“Scrum: An Extension Pattern Language for Hyperproductive Software Development

That is the process adopted can define and constrain what’s thought think is possible: really, this is a more detailed re-statement of the old, “think outside the box” maxim.

Reduced to that cliche, it seems too simplistic. However, there’s nary a group that hasn’t been hurt by strict adherence to their methodology or technologies.