A viable stand-in for every free-form poem

He fired an electric beagle at her.

Oh no!  Cumulus hairballs in a Tycho lace hack!

It was too late to return the pancakes.

Sentio Ergo Sum

My friend and current boss, Al Shalloway, has been talking with be about cogito ergo sum for a little while, now.

While I think the ergo sum part is the critical insight - the recognition that your knowledge is limited to your own existence - he's been debating the cogito part.

The assertion I think he's making is that you don't think.  I don't know if I agree but I definitely have become convinced that you don't know you think.

You do, however, know that you experience.  At least, I know that I do.  Moreover, I don't know anything else.

So I wonder if the sentio ergo sum is a more appropriate declaration.  It still contains the essential assertion underpinning all reason: that we basically don't know anything.  It's actually a stronger statement of that fact.

Cogito Ergo Sum

First, I'll Rant About How Crazy People Are...

If you're one of those people who is insane but can't face it so you call my ideas nuts, you might want to skip this section.  You know who you are (but can't admit it).

When I learned about Descartes's discovery.  I learned from someone who understood what it really meant.

I'm referring, of course, to the discovery he made that mattered most, not all his contributions to mathematics.  His mathematical contributions were great but, next to his philosophical contributions, they are a mouse fart on the Yellowstone Caldera.

It has come to my attention that there are some insane people who have interpreted "cogito ergo sum" as the foundation of all knowledge.  This is false.  That discovery is the root of all doubt.

The fact that the only knowledge you truly have is that there is an observing thing doing something you call "thinking" that you call "I" means that everything else you call "knowledge" is actually just a well-supported guess.

It doesn't matter if this was his intent.  This is the correct interpretation of his findings and it is why he won philosophy regardless of what he meant.

It sure looks to me like he meant the right thing but there's no point in arguing with someone over what a dead guy meant.  If you don't believe me just go count up all the Christians who think they can use the words of the most world's most famous pacifist to justify war.  So I'll just say that the right interpretation is the right interpretation and move on to my real point.

Doubt as an Exploratory Tool

The tool Descartes used, as I recall it, to arrive at his critical discovery is a powerful tool and I don't think it's done all the work it can.

First, let me introduce a similar tool I first heard of by reading the Heath brothers book, Decisive.  One of the thought-tools they suggest for widening your options is a mental game called "the vanishing-options genie."  In this game, you pretend that you have a reverse genie following you around taking away options (rather than granting wishes).

I've seen this tool help people break out of narrow-frames of reference when making decision.  It's very effective.

That got me thinking, can we use a great Deceiver to do the same thing with our analyses?  So often, I find that humans (myself included) want to stick to what they know.

We start with a thought and say "Is this true?"  Sometimes we say "How might this be wrong?"  Either way, we're starting with a point-of-reference that shapes subsequent thoughts and actions.

One tool that helps me is to use Descartes's omnipotent deceiver as a stand-in for the vanishing-options genie; instead of being a vanishing-options genie, it's a vanishing-assumptions genie.

Basically, when you are trying to understand why something works the way it does, take something you know to be true and assume it's actually one of the Deceiver's illusions.

I find this helps me branch out and consider alternative interpretations more readily.

Implementation

In case my previous suggestion was too abstract, I'll throw some examples in here.  The examples of knowledge to abandon are just placeholders; you'll need to pick stuff relevant to whatever you are considering.  The examples of kinds of replacements are probably reusable.

One way to do this is to replace the "illusion" with a "truth" - an alternate reason why something works the way it does.  For instance, you could say "it's not going faster than the speed of light, it's just going back in time."  Or, if you're one of the nutjobs who already believes that kind of crap, flip it around and see what happens.

Another option is to replace the "illusion" with an admission of ignorance.  Instead of "pull works because it aligns the efforts of many people toward a single goal and organizes their work in a delay-minimizing order toward achieving that goal."  You can just say "I don't know why pull works."

A third option is to replace an "illusion" with an assertion of illusion.  Replace "gas makes the car go" with "gas doesn't make the car go, something else does" and see what happens.

Try It...Or Don't

It works for me and it works for other people.  Try it and see what happens.  You know...or don't try it and don't see what happens.

All malaria is saying...

...is give peace a chance!

Sitting in Ringo Starr Concert

I'm sitting in the a Ringo Starr concert in Bend, OR and realizing that the Boomer's greatest achievement is not completely reversing six thousand years worth of advancement.

Way to go guys.  You barely didn't do it!

Canceling my iContact account

All these people who talk about how hard it is to cancel their iContact accounts... I don't know what they are talking about.

My cancellation was a two-step process:

1. Send them an email informing them that I wish to cancel.
2. Confirming that I wanted to cancel when they asked if I was sure.

My total investment in the entire process was less than forty-five seconds.  The cycle time on the process was about ten hours, most of which were during the night-time.

Maybe there are some circumstances where it is hard to cancel with them but I certainly didn't experience it.  All in all, I was happy with the service they provided.  I would recommend it to anyone who needs to build and maintain that kind of mailing list.

The Fermi Paradox is ridiculous

If it serves a purpose, it is just to illustrate Man's hubris.  There are so many fallacious assumptions and assertions in every version of it that I've heard.  It's not even worth debunking.

I know the Fermi Paradox is all the rage, right now.  Please, people, try to retain a little intellectual dignity when evaluating this kind of garbage.

We Don't Need Campaign Finance Reform, We Need Campaign Audience Reform

People bitch about campaign money all the time.  An argument that is regularly made can be paraphrased as follows:

The campaign with the most money can buy the most votes so we need to modify how people get funded to ensure their interests align with the people's.

This is a specious argument.  The problem is not that we must control who has the money to buy the opinion of the voting public so that the right opinion is bought.  The problem is that we let people vote who are so easily influenced that an insubstantial, 30-second advertisement can change the course of their actions.

Think about it.  Is it really reasonable that someone who, essentially, votes in accordance with the last advertisement they happened to hear should be given the power to choose who lives and who dies?  Of course it isn't.

...and don't kid yourself.  That's nothing short of what voting is: the power to kill someone who disagrees with your choices strongly enough to not comply.  Sure, it's filtered through dozens of layers of indirection - judges, juries, laws, cops, et cetera - but that doesn't make voting any less what it is: the power to compel under threat of death.

Most people - even really, really stupid people - would agree that one guy shouldn't be allowed to take whatever he wants and kill whomever tries to stop him.  Nearly one-hundred percent of that group would agree that the power should no more be granted to two or twenty such people.

In fact, the public response to organized crime - groups of people who compel under (ultimately) the threat of death - seems to indicate that many of us have an implicit grasp on the non-linear nature of this kind of problem.  That is, everyone seems to know that two thugs are a little more that twice as bad as one thug.  Most of us know that a large organization that takes what it wants and kills those who try to stop it is a really dangerous, bad, and - dare I level a value judgment? - evil thing.

So why is a group of four-hundred million people doing the same thing somehow magically better?  Why do we care about the opinion of someone who just wants to vote themselves money?  Their vote certainly shouldn't count.  Why do we care about the opinion of someone who is persuaded by arguments like "Yuh-huh!" and "Nuh-uh!"?  Isn't that person's opinion noise at best and, at worst, and amplifier for the person who can buy the most ad-space in their field of view?

My dad likes to complain about how we live in a marketing-driven economy.  We all see some huge number of advertisements every day.  Corporations are using those ads to drive people's behavior.

How the hell is that the corporations' fault?  You see the ads.  You choose how (or, I guess in some people's cases, whether or not) to interpret them.  If you elect to be a subject of the media's sway, that doesn't make the corporation at fault.  It's your fault.

If I was playing chess with you, you'd not fault me for exploiting an enormous opening you left me, would you?  It's no more wrong for a company to exploit the weak minds of its potential buyers.  It's no more wrong for a politician to buy an ad spot that says there's no proof his opponent isn't a lizard man who worships the devil and eats puppies.  It's no more wrong for a major lobby group to fund that ad.

If there is any fault to be assigned - and, given the current state of affairs, I believe there is - it must be on the people who are influenced by such things.  If someone is too simple to vote properly, it is their own fault, not the fault of the people who take advantage of that fact.

A simple thought experiment can demonstrate this.  Imagine this scenario:

Ninety-nine percent of the voting public bases their decisions on their own thoughts.  That is, they take their own experiences, values, and judgments and synthesize a model of the world then base decisions on that model.  One politician's promises and track record jives with the model developed by fifty-five percent of those thinking voters - more than half of all voters.  His opponent has ten times as much funding but they both have enough funding to reach basically all of the potential voters.  Who's going to win in that scenario?

Naturally, it would be the person whom the thinking people believe will accomplish what they want accomplished.

Now flip it around.  One percent of the population thinks and the remainder votes in accordance with the number of advertising dollars to which they've been exposed.  In such a case, funding would be almost the only thing that matters.  If you imagine the same funding bias, it's pretty obvious who is most likely to win that election.

Both cases have a huge funding bias but only one has a corrupted election, the one where corrupt and weak people are allowed to vote.

We don't need better campaign financing rules.  We don't need better rules around advertisements.  We just need to start taking responsibility for our actions - including the act of voting - and peeling off the mantle of power the sticky fingers of anyone who can't or won't do that.

Another Generally Positive Review for Test-Driven Database Development

I would be a fool to think that my first book would receive only positive feedback.  This review, I think, is excellent.  I like it for three reasons:

1. My own self-interest
2. The reviewer clearly understood what he was reviewing
3. It contains actionable criticisms that will benefit a 2nd edition, if there is one

Vanity of the Database Authors

Mr. Carlson's review is, I think, generally positive.  This means that it will cause more people to buy my book, which is nice.  It also means that it fans the flames of my own vanity, which is really nice.  Most importantly, though, it means that more people are likely to actually read my book which, in turn, means more people are likely to take a sane approach to database development.

Deep Understanding

The author of the review in question clearly took the time to read, understand, and evaluate the concepts in my book.  I think a lot of people who buy books do this but, for some reason, only about half of people who write reviews appear to do it.

Mr. Carlson didn't necessarily understand all of my motivations or what I know about outside the scope of Test-Driven Database Development: Unlocking Agility but... hey... who's fault is that?  Right?

Actionable Criticisms

Not everything Mr. Carlson has to say is positive but those bits which are negative are highly actionable.  He says I give the appearance of not understanding normalization.  I do understand how to do it and why people do it in addition to why it actually should be done.  However, looking back, I can see how someone might get the impression I don't if they were basing their opinion solely on my book.  In the 2nd edition, I will remedy that by adding material that addresses those kinds of concepts.

Likewise, he makes the point that I don't address object-relational-mapping at all.  He rightly guessed that it is because ORM runs contrary the message I send - databases as instances of classes with tightly-controlled and rigorously-tested sets of exposed behaviors.  Nevertheless, his argument is that ORM is a very popular concept in designing interactions with databases is true.  If I ever get to do a second edition, which I happily think I might, and ORM is still popular, which I sadly believe it may be, then I will address it at that time.

I may address those concepts sooner, too, in the form of blog entries or articles.

Being a Jerk Is Only the Beginning!

It occurred to me while I was writing yesterday's entry.  That there is a cute little play on words to be had.  I wrote this post then and couldn't resist posting it today when the word "jerk" is flying around like hail in a windstorm.

I'm a Big Jerk

In physics, jerk is the 3rd derivative of position over time.  That is, velocity is the derivative of position, acceleration the derivative of velocity, and jerk is the derivative of acceleration.

In business, if you allow yourself an analogy between value-delivered and position, then some interesting parallels become apparent.  Your product would be analogous to velocity, as it is what continuously delivers more value.  Developers would then be agents of acceleration - constantly working to improve the product and increase velocity of value-delivered.

It would follow that technical leaders who take an interest in developing the skills of those around them would be agents of jerk - working to improve the rate of acceleration.

So yes, I am a jerk.  For the last eight or so years, it's been my primary objective to be a big jerk.

At long last, I can wear the label with pride.  Who am I kidding.  I've always worn it with pride.

To Jerkdom and Beyond!

Sometimes, though, I'd like to think I'm more than a mere jerk.  The fourth derivative of position over time is called "jounce."

Lately, I've not been as interested in being a jerk.  I've wanted to grow beyond that role and jounce seems like just the ticket.  What exactly would parallel that in the software development world?

I think a good analogy is leader-making.

As I get older and wiser, I take more of an interest (and show more aptitude) in developing new technical leaders.  Not that I'm anywhere near the level of Al Shalloway or Scott Bain, both of whom I consider to be my mentors, but I am starting to gain some traction nonetheless.

So, every once in a little while, in addition to being a big jerk, I'm a little jounce but, over time, I'd like to get more jouncy and less jerky.

Orthogonal Kinds of Growth

Anyway, it occurred to me that this is the real ladder of skill to climb.  Sure, having a better product is good but having a sustainable way of making it better is better.  Sure, having a sustainable way of improving a product is good but having an accelerating way of improving it is better.  You get the idea.

Being an expert developer is good and important but it is not the end of the journey.  There are other kinds of learning that are very important.

Going from being an okay developer to being a good developer is mostly a matter of practice and study.  Going from being any kind of developer to any kind of leader is a qualitative change.

At least, for me, it was.  It required (requires?) a fundamental shift in how I think about and interact with people and in what kind of problems I consider.  Going from being a leader to helping develop leaders probably requires just as big a leap but I'm so new to it that I can't really say.

Here is a handy picture I composed illustrating the distinction between kinds of skill and level of skill within an organization.

Planning Ahead

So, if you're a young developer and setting goals for yourself, you might want to consider that there is more than one dimension to your growth.  You can (and will need to) make yourself a competent programmer but you can do the most good by going from being a good programmer, to a leader, to a leader-maker.

If you work hard, maybe one day you can become a big jerk like me.  I'll do my best to be a bigger jerk by the time you get there and, if I'm lucky, I'll be more than just a big jerk too.

Technical Leadership Is Leadership

Being a technical leader can involve a number of challenges.  Between outside forces, long- and short-term pressures, legacy systems, and complex problems an architect, lead developer, or development manager has a lot on his plate.

Many of the most skilled programmers are comfortable with those kinds of challenges.  For a lot of technical people that's the only kind of problem with which you are comfortable.  Whether, like me, you are arrogant and demanding or, like many others, you are shy and reserved, there is a decent chance that you don't count people skills among your strongest.

Yet the technical challenges only represent half of the problems facing a technical leader.  To be truly effective, you have to be a leader of people in addition to a setter of technical direction.  That is, unless you want to do everything yourself.

I'm not saying that every kind of management problem necessarily rests on the shoulders of a technical leader.  I do believe, however, that empowering the people you work with to make better technical decisions on their own will have an enormous impact on your effectiveness as a technical leader.

For instance, I recently wrote an article for InformIT that touches on the subject, entitled Five Ways to Optimize Encapsulation in Your Software Architecture.  In most scenarios, every single step requires someone to not just be a leader in the area of design and architecture but also a leader of men.

For me, this is the biggest kind of challenge available in the software world.  It's hard and rewarding.  Sure, there are things that are harder - like trying to maintain really terrible legacy code - but those things aren't as rewarding because so little is accomplished in exchange for so much energy.  There are areas where I have more success - like maintaining code that was written the modern way - but that's not as rewarding because so little energy was exchanged for the benefit obtained.

Building up people's skills, guiding them, helping them grow, and influencing their decision making meets all my challenge criteria.  At least, it does now that I've become interested in that level of challenge.  It requires patience, understanding, and a close approximation of empathy - things that don't come easily to me.  On the other hand, in exchange for the enormous effort involved, you get enormous value.

The worst likely case is that you fail and nothing happens.  In the software industry, that's actually a pretty good bad scenario.  Once you develop your mentoring and leadership skills, the most likely case is that you will permanently modify how effective someone is as a programmer, building up a portfolio of recurring dividends over time.  Sometimes, you will help someone else become a true technical leader, improving the rate at which dividends are increased.

The rate of return on this kind of effort is very, very high.  For most of us, there's nothing more rewarding than hard work with a high rate of return.  So, the next time you're considering your position as a technical leader, try to think about how much time you spend leading people not just products.

Referencing Concepts from Presentations

I've been delivering shorter presentations of late.  To keep things compact, I've been experimenting with just saying "I'm assuming you're familiar with these things.  If not, there are resources to help you with them."

For audiences that do know the things called out as assumptions, this has worked really well.  What hasn't worked so well is when the audience doesn't really have a good understanding of a body of knowledge that I reference rather than cover.

In retrospect, this is obvious but I certainly failed to predict it.

I'm grappling with a number of possible solutions.  I'll probably think of more later but here is what I can think of now:

• Keep materials on hand that address assumed knowledge and adapt a talk to the audience's needs.
• Do a better job of determining an audience's needs in advance and screen out ones that don't have the prerequisites.
• Do a better job of determining an audience's needs in advance and pre-adapt a talk before showing up at the venue, setting expectations appropriately in the process.

I don't know where I'm going with this but any suggestions would be welcome.

Test-Driven Architecture Article Published

The article my friend, Mike Brown, and I wrote has been published.  The topic is how to apply test-driven development to architecture.  You can find it here.

Another Article Submitted

I've submitted a third article about architecture to InformIT.  This will probably be my last one for a while.  I want to go back to focusing on the database stuff.  This most recent article has a moderately interesting story.

It started out as a position statement: Encapsulation is the most important thing in architecture.  Encapsulation is already the most important thing in any software development effort, so that ended up coming off a little pompous.

I then rewrote it as something that addressed the root motivation which underlies encapsulation: longevity.  That article ended up being interesting but it didn't talk enough about encapsulation, which was the original point of the original article.

I settled on the working title "Five Tips to Maximize Encapsulation in Your Architecture" and I have received word that it will be published on February 20^th, 2014.

I'll post a link when it is published.

Why Revision Control is Not Enough

Several people have suggested that revision control might be an alternative to creating a class of databases.  I really have no way to counter such an argument because I cannot fathom what they were thinking in the first place.

The two concepts target completely and utterly different things.  I guess that all I can really do is talk about how different they are and hope some people change their stance.

Revision control (e.g.: CVS, Subversion, or Perforce) allows you to track and manage the changes you are making to source code.  The point is to (a) provide a place of safekeeping for your documents of design and (b) to allow you to access previous versions of a design.  When you update the design of a class, you create a new version of it in source control and do not generally see older versions unless you go looking for them.

The point is to allow you to work on the most recent design in a particular branch while keeping a history of what was done and not betting on a single computer to keep your source code safe.  In short: Source control is about managing the relationship between developers and designs.

A class of databases has a totally different functions.  Like any other class, it's most interesting relationship is between it and its objects.  Yes, a database class must store the steps required to build older versions in it but for a totally different reason that why a version-control system stores older versions of source code.

Whereas a revision control system tracks versions for the benefit of the development process, a class of databases must track revisions for the benefit of the database-construction process.

Storing the incremental deltas required to get from each version to the next and forcing all databases in a class to follow the exact same path of growth enables test-driven, agile database development in two ways.  For one thing, it drastically simplifies the database deployment model; every single database of a given type grows exactly the same way.  For another, it allows you to properly test the transitions from one version to the next.

The versions of a source file are created because a developer has learned something, changed his mind, or otherwise revised design and they are created to ensure that developers can revisit previous designs.  The versions of a database class are created because a revision to design was actually released to production and they are created so that every database in a class is built in the exact same way as every other database in that class.

Encapsulation of Database Design

It seems to me like every software developer goes through a phase where they think stored procedures are bad and a phase where they think they are good.  Like me, some alternate through these positions several times before settling on a position that works.

In the end, I discovered that there was never a dichotomy in the first place.  The real question was not whether to use stored procedures but how to use them.  The struggle over whether or not to use stored procedures was never really about stored procedures.  It was always about properly separating concerns and encapsulating designs.

In the Beginning...

I started off loving the idea of stored procedures.  I loved them based on a single argument that, at the time, was possibly relevant: performance.  That pernicious specter that looms over our industry, the myth of proactive optimization, cast its spell over me and I was totally sold.

In the nineties, it might even have been true that there was a compelling performance-based reason to write a stored procedure.  In general, for modern database systems, that is no longer the case.

Flip

As with many people in the pro-stored-procedure camp, I ran into one of the many potential failings of heavy stored-procedure use.  Putting behavior in a stored procedure because it is "faster" or "more appropriate" often drives bad design decisions.

The more logic I added to a database, the harder it was to test.  This was before I stumbled into the ideas in my book but it would still be true, at least to some extent, today.  Also, the fatter I made my database layer, the thinner I made the other layers.  The coup de grace was the fact that, on a regular basis, large stored procedures were actually slower than performing dumb selects and processing the data into meaningful results in a middle-tier service.

Essentially, every time I transferred business logic from somewhere more appropriate to a database, I made my system harder to test, less flexible, and slower.  So I did what humans often do and switch from one extreme to its opposite: no stored procedures of any kind.

Flop

The problem with toggling between extremes is that it reduces the world to binary decisions.  Of course it is true that, in any decision, one is considering a finite set of options which can be reduced to a series of binary decisions.  There's nothing wrong with choosing between two things but there is something wrong with limiting your options early in the decision-making process.

The "no stored procedures" stance didn't work out very well either, although it does work better than "everything in the database" way of working.  Instead of a tightly-wound, change resistant machine that served as the center of an application's universe and ground change to a halt, I was building delicate arrangements of glass work that shattered at the first hint of change which served as the center of an application's universe and ground change to a halt.

The problem with not having any stored procedures is that something has to have an intimate relationship with the structure of a database.  When the stored procedures go away, that tends to become whatever is connected to the database (usually a middle-tier service).

That kind of intricate understanding of implementation details between one module and another is inherently more difficult to enforce that such an understanding residing exclusively within a module.  It drives the cost of change through the roof.

The Other Way

As is often the case, the artificial binary decision was hiding the true nature of the decision in the first place.  The question was never "should stored procedures be used or not?"  The right question to ask is "for what should we use stored procedures?"  Note the "yes" and "no" answers to the former question map to answers in the latter but there are many other potential answers as well.

I don't want to iterate through all the possible ways stored procedures could be used in a database design; mostly because that list is probably infinite in length.  So I'll just cut straight to the one that I think is right: encapsulation.

A while back, someone I was working with, Christopher Taylor, suggested to me that stored procedures were the equivalent of a class's interface for a database.  They are a contract between a database and its clients.  So long as the contract is fulfilled, you are free to revise the implementation details to your heart's desire.  He didn't use these words and I don't recall the exact words he used but it the point is that it was he who turned me on to this idea.

Database Designs Require Encapsulation

Probably the most sapient portion of the observation had little to do with stored procedures, specifically.  Stored procedures are merely a tool we use in recognizing that databases need encapsulation of their designs just the same way that any other object would.

Depending on the features available in your chosen database platform, you could conceivably create encapsulation other ways.  For instance, some platforms allow updateable views.  So long as you could keep satisfying the contract specified by an earlier set of exposed tables, you can change the design of your database behind that wall of encapsulation.

As Scott Bain says, encapsulation is the first principle of design.  It should come as no surprise that this is true for database designs.