Do You Have a Jesus Problem? Alcohol is the answer.

Do you frequently get high on Jesus or Moses when you are alone?  Are you afraid to talk to your friends about where you went last Sunday?  Do you hide bibles around the house so your spouse can't find them?

These are all signs of religion abuse.  Religion abuse is a very serious condition that affects nearly two out of every three Americans.  If you don't suffer from religion abuse, look to your left, then to your right.  Both of those people probably do.

The affects of religious abuse last a lifetime.  Long term religion abuse can affect your personality, making your presence less pleasant or even unbearable to others.  People who are high on religion are often extremely suggestible and will do practically anything to "score" a shot at "heaven."  Worse still: people who abuse religion often pass their condition on to their children.

Even though it's completely ridiculous, these facts show that religion is no laughing matter.

But... if you suffer from this condition, I have some good news: there is a way out.  By giving yourself over to Alcohol, you can blind yourself to the evils of the world.  Through Its powers, you will become blissfully unaware of your suffering and will no longer feel the need to justify it by contriving fictitious entities who watch over you and have a "good reason" for putting you through a living hell.

And the wages of delusion is death of joy, but in Alcohol there is joy everlasting.

 Remember: you don't have to live like this.  You can think for yourself and you can find a way to cope with the cold, barren, empty void that is our existence without depending on imaginary figures from ancient fairy tales.  In Alcohol, there is redemption.  Turn yourself over to Alcohol and start living your life.

The New Threat: Global Sideways-ing

People just don't get it.  Ever since several groups started trying to warn us about man-made global warming, there's been a small cadre of crackpots who've said crazy things like "Wait a minute!  Isn't the Earth just going through its normal cycle of warming and cooling?" or "Hey!  It seems like we shouldn't be worried about global warming when the Earth is near the bottom of it's ordinary temperature range."

Oh sure, the scientific and media community has been able to throw together some numbers and change their language against statements like the latter by changing "global warming" to "climate change."  ...but the threat those people pose still remains.  How exactly do you deal with it when someone has a modicum of knowledge about the Earth's climate history in a larger context, one that generally does not include man?  How do you handle pesky lunatics who want to point out that tens of thousands of years ago could not have been the last ice age because it was part of this ice age and, in fact, we are in what is known as an "interglacial period?"

You can try and show how insane they are for pointing at things like "evidence" and "historical data."  I'm sure that's what these fine, upstanding people would say is the right course of action.

However, I would like to point out that those of us who do believe in global warming; those of us who keep the faith in spite of the evidence - because that's what it's about, after all: keeping the faith - have been focusing on the wrong thing...

You see, this is a complex problem full of complex numbers and, as everybody knows, complex numbers have two components: the real part and the imaginary part.  Our problem is that we've been trying to convince people that man-made global climate change exists using real numbers and the real numbers have been very uncooperative.

What we need to start doing is helping people comprehend the threat posed by the imaginary numbers.  After all, the true threat lies in the imaginary component of the evidence we have collected, rather than the real part.  Let's look at a concrete example.

Let's say that last year, the global average temperature went up by 0.1°F - don't bother to fact-check, I made that up as a hypothetical.  Someone could argue we have absolutely no evidence whatsoever that, when exiting an ice age, the temperature should not go up as fast as it did.

What these people don't understand is the imaginary impact of that change and the very real threat it poses.  Let's take a closer look:

While, in our hypothetical example, the real component of climate change was only 0.1°F, the imaginary component could be 10i√(°F).  The good news is that we have no way of measuring this number so there is no way for those "that's not what the evidence suggests" fruitcakes to show that they are completely fabricated.  The bad news is that same attribute makes it so that those same nut jobs can say "because we cannot measure it, it won't have any measurable impact on our lives."


This can be resolved with the simple remedy of applying "what if;" the tool we used to generate a buzz and get people worried about global warming climate change in the first place.  All we have to say is "What if some event were to occur that caused the imaginary portion of our climate change to be squared?  Where would be be then?"

If our actual global average temperature were, say 67°F + 10i√(°F), and the imaginary portion were to be squared, the real part of our global average temperature would drop 100°F - a global catastrophe.  Likewise, if the temperature started out as 67°F - 10i√(°F), the temperature would jump 100°F - killing pretty much everything everywhere.


This proves, I think, that the real threat is not global warming, weirding, or climate change but Global Sidways-ing, man-made changes to the imaginary portion of our global average temperature that could lead to very disastrous consequences if mathematics were to fundamentally change in a way that caused those imaginary numbers to become real.

Living without Dryer Sheets

Now that I live in Bend, one of my biggest problems is static electricity.  Every time that I reach for my computer at work, I get shocked; sometimes hard enough that the affected finger goes a little numb for a few minutes.

Another problem I have is that I am lazy.  Horribly, horribly lazy... at least when it comes to mundane things.  Ask my wife, she'll confirm: I'm the laziest person there is.  Think you're the laziest?  Wrong.  It's me.

So, long story short: I don't have dryer sheets because I am too lazy to walk across the street and buy them.  So my static electricity problem is worse than ever before.

Problem: My pants carry too high a static charge.

Solution: Wrap them around the faucet while I'm brushing my teeth.

Faucets are pretty well grounded things.  Wrapping your clothes around them for a few minutes will drain them of most of their static charge.

So, if you are lazy and don't want to go get dryer sheets - or maybe your one of those new-age enviro-douches who lives in constant fear of the dryer-sheet-ocolypse... whatever the case, if you don't want to use dryer sheets use the faucet to de-staticify your clothes before you wear them.  You have my personal guarantee that it will work.^*

* Personal guarantees made by Max Guernsey, III are backed by nothing.  Void where prohibited.  Void where permitted.

Your Last Chance to Sign up for My Database Agility Course is Approaching!

Tomorrow, the Early Bird Special prices for the March-April Database Agility Online Training will expire.  Although I will probably start another one no later than July, my schedule is pretty hectic so don't assume that I'll be starting one in May or June.  I might but I cannot make any promises.

For those of you who don't know what this course is about: it tackles the critical problems that make Agile software development difficult in the database domain.

Automation and Value Streams

Recently, I release a book called "Goad Testing: Deepening our Understanding of Automated Tests."  While the general purpose of that particular writing is to help people find ways to keep their bed of tests as healthy as the tests help them keep their production code, it also hits on something that I believe and I talk about implicitly but never call out as a topic of its own...

Automation of any kind - programs written for customers, machines that build cars, video games, and, yes, tests too - are really instruments of process improvement.  In every single case they have no less than one of the following effects on some value stream:

• They provide access to information which enables the completion of a step
• They reduce the amount of time a step takes
• They improve the quality of the outcome produced by a step

...and really, these all resolve down to a single impact:

Every piece of useful software reduces the amount of time required to complete some step in a value stream.

Whether or not the amount of time required without software made the step in question infeasible or caused the quality of its output to suffer is irrelevant, it's all a function of not being about to make a decision, come to a realization, trigger an action, store your findings, etc. quickly.  There is nothing that software can do but we people cannot, given enough time.  Even the fact that software runs the same way every time it is executed in the same context translates into an impact on the time it takes to get something done by minimizing the potential for rework.

It all comes down to time and process, which is what Lean told us in the first place.  The customer for a test just happens to be the development team that will use the test to avoid releasing crappy software to their customers.

Why does this matter?  ...because people bandy about all these different explanations of what tests "really are..."

• A test isn't really a test... it's a specification
• A test isn't really a test... it's process control
• A test isn't really a test... it's a performance metric

Tests have the side effect of eliminating the need for a lot of those things but, at the end of the day, a test is a piece of software that reduces the cycle time of a development team by eliminating delays between the introduction of a defect and its discovery.

A.K.A.: a "test."

Some Guy's Crazy, Cheesy Dream

This guy's trying to take $250k from Dorritos so that he can fight cancer and stuff.

Check out his video here.

Branching with Design

Code.  Code never changes. 

The end of the world occurred pretty much as we predicted.  Too much duplication.  Not enough manpower to go around.  The details are trivial and pointless.  The reasons, as always, purely human ones. 

(adapted from the beginning of the last real Fallout game)

 I hate branches.  I hate them... and why shouldn't I?  Here is the promise of a branch...

We're going to defer integration for a long time so that it will cost more when we do it but don't worry, until the branch is merged, we're going to essentially maintain two copies of the same code base.  Make that three.  Make that four.  Make that... ah fuck it.

Recently, a pretty decent argument was made in favor of branching...

We have to change X.  Whenever we change X, everyone on the team is broken for months.

Naturally, the first response is "Well, it shouldn't be that way."  To which the person with whom I was having the debate replied...

I know but it is.

Check...

We're trying to fix it but that's the way things are right now.

 ...aaaaaaand mate.

The team understood that it was a huge problem and wanted desperately to fix it but didn't have the resources to do all of the necessary refactoring before they had to change X.  Because of the size of the system, its complexity, and the level of encapsulation around X, there were going to be breaks; no "if"s, "and"s, or "but"s about it.


So what to do, then?  The answer is, as I'm sure you've guessed now, to branch with design.  What, precisely, does that mean?  The steps can be summarized pretty simply as follows:

1. Find the places where X, is used and its behavior needs to change.
2. Create a Facade that exposes just the functionality needed by those touch-points.
3. Promote the Facade to an abstraction with its only variation being the classic usages of X.
4. Make the old behavior the default variation of your Facade abstraction.
5. Create another variation into which the new behavior is placed; provide QA with a place to "turn on" the new behavior.

The alternate behavior can be a Proxy to X, an alternate implementation... it can even be incomplete or not work - it's not being used in the normal "production" code path.  Yet, your "branch" is continuously integrated.


Without even touching your continuous integration configuration code, your "branch" will be built with the rest of the code.  If a test fails against it, your build goes red.  If you forget a semicolon, your build goes red.  You will receive continuous feedback as though you didn't branch... because you didn't.  Yet you will be able to insulate people working on other things from pain caused by your changes as if you did.


Now, I'm not claiming this as my own.  It would have to be crazy to do so as it is basically nothing more than a narration of how the Facade pattern plays out when you pursue it aggressively.  My point is not "Hey!  Look at this neat thing I invented," because I didn't invent it.


Instead, my point is that you can always do this and it always works.  I'm sure that, somewhere out in the world, someone has a good reason why they absolutely have to branch.  Disregarding such one-in-a-million scenarios, you should always branch with design rather than with source control.  It's safer, cleaner, and lower cost.