Max Guernsey, III

A viable stand-in for every free-form poem

Max Guernsey — Fri, 26 Sep 2014 20:48:00 +0000

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

Max Guernsey — Tue, 09 Sep 2014 21:00:00 +0000

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

Max Guernsey — Sun, 07 Sep 2014 13:55:00 +0000

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...

Max Guernsey — Thu, 17 Jul 2014 20:32:00 +0000

...is give peace a chance!

Sitting in Ringo Starr Concert

Max Guernsey — Thu, 17 Jul 2014 20:00:00 +0000

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

Max Guernsey — Thu, 10 Jul 2014 12:06:00 +0000

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:

Send them an email informing them that I wish to cancel.
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

Max Guernsey — Tue, 01 Jul 2014 22:07:00 +0000

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

Max Guernsey — Wed, 23 Apr 2014 20:55:00 +0000

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

Max Guernsey — Thu, 10 Apr 2014 08:19:00 +0000

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:

My own self-interest
The reviewer clearly understood what he was reviewing
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!

Max Guernsey — Tue, 08 Apr 2014 08:51:00 +0000

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

Max Guernsey — Mon, 07 Apr 2014 08:50:00 +0000

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

Max Guernsey — Tue, 25 Feb 2014 11:11:00 +0000

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

Max Guernsey — Thu, 20 Feb 2014 13:04:00 +0000

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

Max Guernsey — Tue, 18 Feb 2014 13:11:00 +0000

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

Max Guernsey — Tue, 07 Jan 2014 08:41:00 +0000

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

Max Guernsey — Mon, 06 Jan 2014 09:22:00 +0000

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.

Test-Driven Architecture Article Accepted by InformIT

Max Guernsey — Mon, 30 Dec 2013 12:01:00 +0000

As you may recall some friends of mine and I are working on articles and blog entries intended to reform architecture for the modern age. This is a quick note that the article Mike Brown and I wrote regarding the impact of TDD on architecture has been submitted to the publisher and is in the editorial phase.

I'll post something here when it is published.

The Version Manager

Max Guernsey — Fri, 27 Dec 2013 11:00:00 +0000

One of the more recent phases in my journey to a class of databases was understanding that the best way to codify a database's design was as the series of revisions that could get you there rather than in terms of specific design elements. It's harder to find fault in this way of thinking because I still use and recommend it today but it was incomplete; sufficient to enable some level of sustainable database development but not true test-driven database development.

Let me refresh your memory on the building technique to which I am referring. You store an ordered list of scripts that are used to build a database. You build some infrastructure that ensures only the right scripts are executed against any given database and in the right order. So, if you have a version 2 database instance and you want to upgrade it to version 5, the infrastructure will execute the steps to upgrade to version 3, then 4, then 5.

Digging the nugget of truth out of this way of doing things is weird because the thing is its own nugget of truth and, at the same time, is not sufficient to support a modern test-driven environment. The reason for this weirdness is that version-based builds are the best way I know to do things but they aren't enough. More was required.

Anyway, the grain of truth in this way of thinking was the recognition that the actual revisions applied to real production databases should govern how we organize database build scripts. That is, while I had not yet discovered the true class of database concept - at least not as I understand it today - I had discovered one of the principles that drives test-driven database development: the historical reality of important database instances must be respected and always trumps our wishes, hopes, and ideals.

Knowledge, Behavior, and Information

Max Guernsey — Mon, 23 Dec 2013 07:30:00 +0000

I mention this in my book but I thought I might elaborate. I think a useful way to conceptually divide the parts of a database is into three groups of design elements: information, knowledge, and behavior.

The Three Concepts

Information and knowledge are often confused in everyday language. So, first, I'll disambiguate those two words. Not all data are information or knowledge and rarely are the two interchangeable.

Information is a special subclass of data. I'm sure someone who is an expert in communication theory or some other kind of academic would be glad to correct me and I won't fight them on what the technical definition of the word is. I'm only interested in what the useful definition for my own purposes is, not the officially right definition. For the purposes of this blog entry, and of everything I say and write, it is the part of a signal that the recipient did not know in advance. Simply put, information is data which informs its recipient.

If information could be thought of as facts in transit, then knowledge would be facts at rest. In essence, knowledge is potential information but it is also a potential driver for action. That is, the two uses of any given object's knowledge are to inform other objects, thereby adding to their knowledge, and to inform decisions, thereby improving the value of an action taken.

That latter purpose is the perfect opening to briefly introduce the third player in the database design world: behavior. If knowledge and information are facts at rest and in motion, behavior can be thought of as how something responds to knowledge or information. For instance, you drive on the correct side of the road because you know you will slam into something if you do. Likewise, you yank your hand away from a too-recently poured cup of coffee have become informed that the cup is too hot to touch without damaging tissue.

Information as Pertains to Databases

In the database world, information is the set of signals sent or received by a database. A query and its parameters, the invocation of a stored procedure, the results set, and any errors that occurred are all examples of information as a database sees it.

In essence, information is the "surface" of a database's design. It is impossible for external parties to access the value of a database except by sending and receiving signals.

Moreover, it is the means by which value is conveyed between a database and its clients. It is pointless to update a database with information it already knows. It is useless to query a database for what you already know. Value is created by such actions that results in one of the other entities "learning" something.

Knowledge as Pertains to Databases

Knowledge is the reason why databases cannot be maintained using the simple "blast and rebuild" upgrade path we apply to most software deployment problems. All the facts stored in a database are knowledge; not all the data, because you can introduce noise into a database's design, but all the facts.

Knowledge is the purpose of a database. Most software products and components exist to convey facts between parties or to process data and discover new facts. Some software exists to entertain. Databases exist to preserve knowledge. Each production database is a modern day Library of Alexandria, complete with the ability for some asshole to burn it down and, in so doing, to cause irreversible damage.

We have known this for a long time - as close to "forever" as matters. Databases have always been designed around the knowledge they capture and preserve. Those design decisions stand as a reflection of our implicit understanding that databases aren't merely data bases, but knowledge bases.

Behavior as Pertains to Databases

So what is the role of behavior in database design? It's another one of those things that can be put simply or drawn crisply, but can take a lot of work to implement correctly. The role of behavior in a database is to mediate between knowledge and information.

All the information that a database receives needs to be translated into knowledge and stored for safekeeping. Why? So that, later, that knowledge can be translated back into information to help other actors make decisions or discoveries.

You can codify the behavior of a database in many different ways. At the time of this entry, the most common way is to couple the behavior offered by a database directly to the kinds of knowledge that database can store. This is accomplished by creating, publicly exposing, and coupling clients to table structures and relationships.

The Relationship Between the Three

I find it useful to divide database design into three parts. The information layer of design is where the interactions between databases and other objects are defined. The knowledge layer of design is where the facts you want to store in a database are housed. The behavior layer is where one codifies the manner in which facts are absorbed or emitted.

behavior translates between knowledge and information

I'll post more on each of the specific layers of design with some implementation recommendations later.

Division of Ideas

Max Guernsey — Sat, 21 Dec 2013 13:56:00 +0000

We choose how we organize ideas in our heads. Take the concept of a wrench. For me, there are two kinds of wrenches: regular wrenches and monkey wrenches. That distinction exists because one kind of wrench is useful for binding while the other is good for bashing. For a mechanic, however, I'm sure there are many kinds of wrenches.

I'm not sure either of us is wrong. Now, I want to be clear: I am not saying that everyone who believes anything is correct because it's what they believe. I am saying that someone who looks at a room full of people and sees two groups is every bit as right as someone standing right next to him who sees three groups in that there is no "right" way to divide things into groups, only "useful" ways to do so.

This may be obvious to others but it wasn't obvious to me. I'm documenting it here as much to ensure I'll have the discovery available for myself when I forget it later as to share it with you.

The Database Installer

Max Guernsey — Fri, 20 Dec 2013 13:30:00 +0000

Another fallacious idea I, and many others, had was to treat database instances like programs that need to be installed. Again, there are many things wrong with this line of reasoning, but something positive came from it.

You know me... "Mr. Positive."

This particular step in my journey to a class of databases bore what was, at least for me, a pretty subtle value. Part of the subtlety came from the fact that the installer paradigm looks like it works for longer than a lot of its predecessors, which tended to break down extremely early. Part of it was my own stubbornness - I was spending so much energy arguing the small improvement that I couldn't see the bigger improvements waiting just around the corner.

I'm pretty sure that's irony: that this way of thinking was so successful kept me from seeing other, more successful, ways of understanding a problem. Wait. Maybe that's not irony. Maybe that's the human condition. ...or maybe those things do not really oppose one another.

Anyway, grain of truth in this way of imagining database build technologies is that it recognizes the importance of discrete, tracked, testable deltas in design and highly controlled, repeatable ways of introducing those changes. That ends up being a pretty fundamental concept. It serves as the basis for building a testable class of databases, enabling test-driven database development, and ultimately unlocking database agility.

So there you have it. Another step in the journey. Another failure to hit the mark. Another lesson that built to what we know today.

Next Step: Test-Driven Architecture

Max Guernsey — Thu, 19 Dec 2013 07:19:00 +0000

Recently, I published an article on InformIT about how we should focus our software-architectural efforts. I've been blogging about it a little bit since.

Like everything in the software development industry, Test-Driven Development can make architecture better. So Mike Brown and I have set out to document our ideas on that subject. Originally, that was going to be a single article on InformIT.

That's not going to cut it. As one might have guessed (I didn't but, now, I can imagine someone else might), the topic is too rich to fit into a single 3,000 word article. So, with luck, it will turn into a series of articles written by my friend and myself (and possibly others) that help this industry take another step toward being truly test-driven.

The Database Design Applicator

Max Guernsey — Wed, 18 Dec 2013 03:30:00 +0000

Another step in my journey to a class of databases was believing that a design tool could properly maintain all my database instances for me. Again, I want to try and dig the nugget of truth out of this belief rather than beat it to death for what is wrong about it.

I think that, in this case, the nugget of truth is actually pretty self-evident. The idea is to have a document that specifies the current design of a database and a tool that can update any database to have that design. If you scrape away the part of that sentence that is obviously magical thinking, you are left with this:

"The idea is to have a document that specifies the current design of a database."

The part that is not quite as readily-apparent is that the motivation runs just a little bit deeper than that. The real drive behind a tool that can update any database to a well-understood definition of the most recent design is that you have a document that codifies the current design and a tool that enforces the current design.

That's a noble goal, actually and an attainable one at that. Think about it...

Disregarding all the ancient ideas, don't we still have a way of doing that when defining a "regular" object model? We just do it a different way. Instead of technical specifications and UML diagrams, we have unit tests. Instead of a tool that generates code from high-level specifications, we have test runners.

Given a class of databases, using unit tests as the primary specification of design is a discipline that transfers straight over to database development; practically unmodified.

So that's the positive takeaway from the era of magical design-application tool mysticism: that we do in fact need a way to specify and enforce the current design of a class of databases and that, like Java, .Net, or C++ classes, that should be automated unit tests specifying how a database behaves and enforcing that specification on a regular basis.

Wrangling Wild Databases

Max Guernsey — Tue, 17 Dec 2013 07:39:00 +0000

I've received some interesting questions lately. One question at my most recent talk for the DAMA group in Portland rang very familiar. It got me thinking.

There are a lot of database instances out there that were developed before my book was published. Even if everyone adopted the techniques therein, that would still leave trillions of rows of data in databases that were not in accordance with the book. Among other things, these databases are generally created with insufficient automated test coverage so, in the spirit of Working Effectively with Legacy Code, I call such databases "legacy databases."

I cover legacy databases a little bit in the book but there is a limited number of scenarios. This blog seems like a natural place to start addressing other issues.

The Scenario

Imagine the following:

You work for a company that sells an enterprise product; we'll call that product "Calm Cheddar." As with most enterprise software products, Calm Cheddar has a database back end. Calm Cheddar has been successful in several applicable markets and has been sold to numerous customers over the course of several years. In that same time, it has grown as a product. Along with the overall design of Calm Cheddar, the design of its database has grown and morphed over time.

manual deployment and broad customer base leads to
deviation in database builds

The final result is that there is an array of customers with varying versions of the software and each with a different path to their current deployment. The saving grace is that Calm Cheddar's customers tend to upgrade to the latest version. They may or may not upgrade often, but then never upgrade to something that is already outdated.

Now let's say you want to start emerging a class of databases in this scenario. What I've shown in the past and what I teach in the first two thirds of my book do not cover scenarios like this. This specific scenario is not covered anywhere and I imagine that there are several people in a similar situation.

The Ideal and the Real

The ideal class of databases is expressed as a linear sequence of versions created using a linear series of revisions. The class of databases is simple, knows how to perform any reasonable upgrade, and is very robust.

Circumstances, however, are rarely ideal.

just because you want it, doesn't make it so

There are at least two lessons from Test-Driven Database Development: Unlocking Agility that apply to this scenario. First: drive variation out of your database build process as much as you possibly can. Second: above all else, make your database build process reflect the actual transitions that have really been applied to real databases.

These two forces might appear to be contradictory but, in fact, they align perfectly. You should drive all variation out of your database development process, yes, but that does not mean you will succeed or will have started autonomating your database build mechanism at the very beginning of your very first database's life. That you should drive all variation from a system does not mean that none will ever be there.

The Reckoning

The key to reconciling these two forces - the impulse to minimize variation in database build paths and the need to recognize the true database upgrade steps that have actually occurred - with the reality that there is a large, diverse population of databases within a given class is in understanding that you must merge these disparate paths together. What was once a vast array of trickling creeks should, over time, be coalesced into a single coursing river of features.

there can be only one

Two techniques must be applied to resolve any differences between the various deployment paths. One is taming a legacy database. The other is remediation deviations.

Without getting into the details, the former amounts to creating a new class of databases that has conditional build logic in its very first version to address the potential of a database that has been built prior to the class's creation. The latter consists of documenting variations in a database's historical construction patterns, then using transition tests to drive conditional logic that reconciles the various "flavors" of a database design.

Sometimes it will be a great deal of time. Imagine that eighty percent of your database instances are almost exactly alike, fifteen percent fall into a few other distinct categories, and the remainder are "lone wolves" with highly deviant paths.

In such a case, you might want to phase your database wrangling activities, starting with the large body of highly similar databases first, moving on to the smaller groups second, and start picking off the lone wolf types on an "as-needed" basis.

This technique works great in a relatively controlled environment where, among other things, all of the databases are roughly the same version. They don't need to all have exactly the same design to start but it does make things a lot easier if they have approximately the same design.

In the Calm Chowder scenario, however, we don't have the luxury. Remember: we have variation in both the version and the manner of construction.

The Conditioner

A friend of mind, Seth McCarthy, has also come up with an interesting twist on this way of doing things; one that, I think, addresses the extra kind of variation.

He suggested adding a proxy over the simple, linear-step-oriented database builder at the heart of a class of databases. This proxy's job is twofold. First and foremost, it detects the version of a database's design then conditions it to look as though the infrastructure for a class of databases has been used to build it. Typically, that means creating and populating some kind of version registry table.

Naturally, if acting on an empty database, the proxy does nothing but delegate to the core database builder.

rectify...

Also, the conditioner code is in a position to perform conditional transformations before delegating to the core class of databases. It can even inject custom transitions in between steps if necessary.

The conditioner represents almost the exact opposite of the linear sequence of database upgrade steps I ordinarily recommend but special circumstances demand special responses. Ordinarily, one would be adding a new version to a class of databases on a very regular basis and one would have to manage an ever-growing number of possible historical versions as a starting point. There should be very little variation between one instance and another of any given version. In that case, having special transformations that go from each version to each other version adds complexity and work.

In this scenario, however, the conditioner proxy exists in the exact opposite context. There's only one target version with which the proxy is principally concerned. There are many source versions and there is the potential for some amount of variation between two instances of any given historical version. So having a special place to handle one or more of the special cases makes perfect sense.

So There You Have It

At a very high level, this should serve as a strategy one could apply to the problem of handling a large, diverse population of databases in various historical states and previously managed with an at least somewhat unreliable process such has being built by hand.

The strategy can be stated simply, though it is not always easy to do. Capture the historical versions of your class of databases. Codify those versions, either as conditional logic in the initial version of a simple linear sequence of modification scripts or as a proxy to a similarly sustainable database class format. Drive each conditional behavior from transition tests that model the variant starting points. Force all of the variation out of existence in a controlled way. If you have too much variation to handle all at once, ingest smaller segments of the source database space into your class of databases.

Tracking Versions in your Database

Max Guernsey — Mon, 16 Dec 2013 07:30:00 +0000

As you may or may not know, I preach creating classes of databases over manipulating the designs of individual databases. There are many different implementation decisions one could make while elevating design from instance to class.

In a previous post, I discussed the shape of the class itself, arguing that it should be organized around actual released versions plus the thing you intend to deploy next. This is not revolutionary. It's not ubiquitous but I'm certainly not the only one to suggest that this is how databases should be maintained.

There are several ways to manage how versions are tracked when an instance of a database has been deployed. One way that I've seen done is to keep a text file with a list of the scripts that have been executed. Another way is to fill a directory with scripts that have been executed, with each script living in its own file.

The way that I think works best and that fits most naturally within the concept of a class of databases is to store the state of a database instance within the instance itself. The alignment is so strong, in fact, that it makes the other methods seem bizarre and beyond the realm of consideration.

Dependency

From a practical perspective, storing a database's version information inside the database only makes sense. You don't want to have something outside a database that is required to run or maintain it. What if that thing gets lost?

the puzzle stops working when
it has a missing piece

Sure, one could make the same argument about the class of databases itself but the odds of a document or set of documents that serve as the source of record for something's design getting lost are extremely low - we have revision control and backup policies to ensure that.

In most environments, the rigorous database maintenance procedures ensure that losing data stored inside a database is many, many, many times less likely than losing a text file or a folder full of scripts. The main way that you might lose said data is if you somehow lost the database itself, along with all its backups, in which case you would probably not care if you also lost the version data for that database.

Management

Another matter of pragmatism is managing databases is that of managing the dependency between them and their version-tracking data. If those data are external to a database instance, then you have to know where they are stored in addition to how to connect to a database.

The most dreadful consequence of this management hassle is that you might accidentally upgrade one database based on the state of another database. Depending on what precautions you take, that could have consequences ranging from a few minutes of aggravation to loss of valuable data.

do you want to feel like this guy?

Moreover, there is a persistent and non-trivial management cost. Everything you do with a database - every single instance you create - also has to have this manifest of its upgrades stored somewhere else and the association between the two must be tracked for as long as the database lives.

What about all those little databases that only last a few seconds or a few minutes? As your test suite is executing? What about all the development databases? It's not like tracking each of these relationships is or expensive but all those little tasks accumulate to produce an awkward development environment fraught with menial tasks that draw your attention from the things that matter.

Principle

There are several different supporting arguments and each, to me, is sufficient but all are derivatives of one overriding factor: objects are only objects if they are whole. In a normal object-oriented environment, access to one object is achieved with a single reference. One pointer to a spot in memory. One connection string to a database instance. Those are a good ways to access an object.

this is not a house
not yet

Imagine if, instead, you needed two things to make an object work. What if a string object stored all its data intrinsically except for its length and, in order to properly use it, you had to track its length in another variable? Could you do it? Of course. Would it be insanely complex? Definitely.

The wholeness of an object is what grants it its identity; what elevates it from being a mere blob of data that can be accessed by a program into an object. Tracking the upgrade state of a database in said database is part of keeping it whole.

You’re still a "traditional" architectur...

Mike Brown — Sun, 24 Nov 2013 15:11:19 +0000

You’re still a "traditional" architecture antibody - in finding a way to perform the duties of an architect that don't make you hate yourself, you've also changed the notion of what an architect is.

By definition, rules cannot be enforced by consens...

Max Guernsey — Mon, 29 Apr 2013 08:20:00 +0000

By definition, rules cannot be enforced by consensus. I'm not sure it's the rules that are creating that effect. I think it might be the community of volunteers policing the material. I wonder how well they would do enforcing style without a codified guide. Nevertheless, you have pointed out an example of a system of rules that does not obviously increase the game-ability of the thing it supposedly guards.

I love the points you're making here. Especia...

Gabriel Behm — Sun, 28 Apr 2013 20:57:01 +0000

I love the points you're making here. Especially your challenge regarding a 'layer of rules' to reduce gaming. Yet I think other sorts of improvements are possible (as you go on to discuss) and I'm not sure I could tell merely from the form of a proposed process change whether it would turn out to be helpful or not. Take Wikipedia's style guide, for example. You could call it a layer of rules but it's special because it's defined and enforced entirely by consensus. Because of that, I think, it meaningfully contributes to the quality of the articles.

I'm glad.

Max Guernsey — Fri, 26 Apr 2013 22:45:51 +0000

I'm glad.

I loved this.

Gabriel Behm — Fri, 26 Apr 2013 20:01:12 +0000

I loved this.

This is why I do not wish to continue this convers...

Max Guernsey — Mon, 22 Apr 2013 06:43:07 +0000

This is why I do not wish to continue this conversation. This is the last of your posts I will read. Not because they are uncomfortable. Because they are wastes of time.

You keep insisting falsehoods are truths. Hitler was elected and then used coercion. The electoral process is not magical, as you seem to think, and does not prevent or negate coercion. As I said, the degree to which people were not coerced is the degree to which they, themselves were guilty.

Likewise in the U.S., there are few (if any) who support the constitution and indefinite detention. There are few (if any) who support human rights and drone strikes. It is your nonsense view of societies as whole things rather than the millions of individuals that they are which creates the contradiction in the first place.

Moreover, your arguments are irrelevant to your point. They are just more noise, not supporting arguments.

One day, the people who believe in personal responsibility will either cast off the shackles of the likes of you or collapse under the burden of carrying the rest of the world on their shoulders.

Your time is better spent preparing for the impending war or dark age than it is trying to convince us our backs don't hurt.

Hi Max, People forget that Hitler was elected. No...

Paul Beckford — Sun, 21 Apr 2013 23:30:57 +0000

Hi Max,

People forget that Hitler was elected. No physical coercion there. Yes he went on to physically brutalise minorities, but that was only once he had gained the implicit consent of the majority... He didn't use force to do that!

Lets find an example closer to home. Americians will talk incessantly about their constitution and their human rights... whilst at the same time supporting the use of drones in Pakistan, and detention without trial in Guantanamo.

Why? Because they are petrified of foreigners and have been conditioned to not see them as people the same as they are...

It is this conditioning to which I speak. There are no logical fallacies here, just uncomfortable truths about the human condition.

Truths that you choose to ignore....

Thank you.

Max Guernsey — Thu, 18 Apr 2013 22:58:23 +0000

Thank you.

Oh, damn. Sorry to hear it, Max.

iesavage — Thu, 18 Apr 2013 22:54:34 +0000

Oh, damn. Sorry to hear it, Max.

No.

Max Guernsey — Wed, 03 Apr 2013 20:17:27 +0000

No.

Also If you haven't heard about Ancestry.com&#...

Anthony Parker — Wed, 03 Apr 2013 18:56:23 +0000

Also If you haven't heard about Ancestry.com's new price change for their Ancestrydna test,they're following 23andme and dropping down to $99. 23andme is still the better deal since there are so may flaws with Ancestry.com's Ancestrydna. A test taker is no better doing Ancestry.com's Ancestrydna than DNA Diagnostics Center's Ancestrybydna 2.5!

Hi again. Have you seen the changes Connectmydna h...

Anthony Parker — Wed, 03 Apr 2013 18:53:34 +0000

Hi again. Have you seen the changes Connectmydna has made again(Connectmydna "3.0")? I think they did it last week.

If my wife sees that comment, then I won't get...

Max Guernsey — Thu, 21 Mar 2013 08:31:23 +0000

If my wife sees that comment, then I won't get my new computer. :)

If I had realized what the issue was, I would have...

Isaac Rabinovitch — Thu, 21 Mar 2013 00:00:28 +0000

If I had realized what the issue was, I would have suggested running across the street to OfficeMax and getting a USB video adapter. About $50.

I updated the entry to have a picture to the previ...

Max Guernsey — Tue, 19 Mar 2013 22:53:58 +0000

I updated the entry to have a picture to the previous entry, in which the only halfway decent pictures I've been able to get of him reside.

This comment has been removed by the author.

Max Guernsey — Tue, 19 Mar 2013 22:51:44 +0000

This comment has been removed by the author.

Yes. It's true. Not every cat expresses anxi...

Max Guernsey — Tue, 19 Mar 2013 19:38:42 +0000

Yes. It's true. Not every cat expresses anxiety at separation. If there's a strong bond, though, most of them do.

This one is so well cared for that I can only imagine there was a strong bond and that he already underwent his mourning period over the loss of his previous family before seeking out a new home.

Pics please. You know, cats are not always uptigh...

Isaac Rabinovitch — Tue, 19 Mar 2013 19:05:10 +0000

Pics please.

You know, cats are not always uptight about being separated from their previous people. Which is not to say you were wrong to claim him, since you obviously did everything you could to find out where he came from.

I just envy you being able to keep so many cats. My lease limits me to two.

I have no problem with encapsulating construction ...

Ken — Thu, 14 Mar 2013 13:15:48 +0000

I have no problem with encapsulating construction in C# and Java. It's pretty much no overhead and follows standard Java usage.

Everything is relative and everyone has their own ideas of what are the cost/benefit tradeoffs. For my viewpoint, these extra lines and their implications are a cost which out weigh the benefit. You have a different viewpoint.

You had me and then you lost me. Now it sounds li...

Max Guernsey — Wed, 13 Mar 2013 19:18:48 +0000

You had me and then you lost me. Now it sounds like you are making, word for word, the exact argument that resistors make against encapsulation of construction in C# and Java:

"I have to type a few extra lines of code in every class to encapsulate construction and I can always just make that class a think that calls another thing."

If I accepted that argument anywhere, I would probably accept it everywhere. I don't, though. I thought you had a stronger argument that the impact on the client was larger because you'd have to separate initialization and declaration. I can address that.

Your most recent argument is not convincing to me at all, however. I don't care if someone has to type a few extra lines. Those lines are cheap. I don't care if debugging is harder. Tests make debugging a rare event. I do care if I can transition from a concrete class to an abstract one with no impact on the client and without having to duplicate the interface of that class in something I demoted to an adapter for its own interface.

What I mean by standard constructor syntax is: ...

Ken — Wed, 13 Mar 2013 19:08:26 +0000

What I mean by standard constructor syntax is:

class MyClass
{
private:
IsConcreteForNow::TransientPointer my_data;
public:
MyClass(int i): my_data(i) {}
};

Without a constructor for IsConcreteForNow::TransientPointer that takes an int, then the code has to be:

MyClass(int i) {
my_data = IsConcreteForNow::CreateTransient(i);
}

What I mean by overhead is that every class with the additions you suggested has to have:

#include “ OnStack.h” // To get the template
class MyClass {
private:
friend class OnStack;
// data members
public:
typedef OnStack TransientPointer;

static TransientPointer CreateTransient(int initialValue) {
.... // implementing code to set data members
}

That’s extra code in every class to achieve flexibility.

Doing a watch on a MyClass object means having to do one more click on “core” to get to the MyClass data members.

I don't think I understand your argument. If ...

Max Guernsey — Wed, 13 Mar 2013 16:23:35 +0000

I don't think I understand your argument. If you could do something like type...

Foo::TransientPointer ptr = Foo::CreateTransient();

...and then have the pointed-to-thing be destroyed when ptr goes out of scope, would that satisfy you?

With the form you describe, you can no longer use ...

Ken — Wed, 13 Mar 2013 13:19:30 +0000

With the form you describe, you can no longer use standard constructor syntax to initialize data members of a class that are of type IsConcreteForNow::TransientPointer. You would need to call the initialization method inside the constructor.

As I mentioned to Scott Bain when he first pointed out your article, I thought it was interesting, but not convincing. I found you have presented an interesting way to be able to apply an overloaded -> operator to a stack variable. But I do not believe that the overhead added to each class to give flexibility is justified, particularly since there is an easy way to give the flexibility (when needed) using the line of attack that I gave in my original comment.

Well. I would probably start by pushing back on t...

Max Guernsey — Fri, 08 Mar 2013 14:43:32 +0000

Well. I would probably start by pushing back on that particular syntax but I assume that...

IsConcreteForNow::TransientPointer transient = IsConcreteForNow::CreateTransient(1);

...would suffice.

I would probably start out with transient pointer being basically what I attached but with a copy constructor and then, if I promoted it to being a heap-allocated object, I would make it an auto pointer that tracked ownership (where assignment or copy-construction "steals" ownership and only the owner deletes) or whatever.

Because you can change what the actual type of TransientPointer is without affecting clients (other than a recompile), you can pretty much do whatever you want.

If IsConcreteForNow required an argument to initiz...

Ken — Fri, 08 Mar 2013 14:28:16 +0000

If IsConcreteForNow required an argument to initizliae it, then I presume you would call something like:

IsConcreteForNow::CreateTransient(transient, 1);

What is your approach to eliminating this call and just being able to declare:

IsConcreteForNow::TransientPointer transient(1);

Keynesian Economics

Max Guernsey — Sat, 05 Nov 2011 10:41:00 +0000

I learned a new word: "Keynesian." Apparently it means this: "The free market sometimes makes imperfect or "inefficient" decisions so we should give some market control over to an entity that consistently makes terrible and wasteful decisions." That, of course, is paraphrased - a Keynesian would never admit that's what he or she is suggesting - but it definitely is an accurate way to describe the school of thought.

Keynes is another example of why academia is mostly a waste of time and money. Before we fire the lawyers into the sun, we should get rid of the economists, the sociologists (including cultural "anthropologists"), and the political "scientists."

Session Materials - "Transition Testing: Cornerstone of Database Agility" - 12.10.2009

Mon, 14 Dec 2009 13:00:00 +0000

DataConstructor v20.09.1805 is released and now available.

DataConstructor SDK v20.09.1805 now available.

Sat, 26 Sep 2009 20:14:00 +0000

DataConstructor v20.09.1805 is released and now available.

iContactProxy SDK v20.09.1726 now available.

Fri, 13 Mar 2009 21:23:45 +0000

iContactProxy v20.09.1726 is released and now available for download.

The BitmapCompare News channel is now open!

Wed, 19 Nov 2008 15:30:00 +0000

An introduction to the Bootstrap news channel.

Free Seminar: Data Structure Metamorphism - May 8, 2008 - Wrap-Up

Sun, 11 May 2008 03:07:39 +0000

Our seminar at the XP users group went pretty well. We got some great feedback and the next one will be better-still.

Free Seminar: Data Structure Metamorphism - May 8, 2008 - Wrap-Up

Sun, 11 May 2008 03:07:39 +0000

Our seminar at the XP users group went pretty well. We got some great feedback and the next one will be better-still.

Part VI: Structure and Information, Revisited

Fri, 09 May 2008 22:43:21 +0000

By Max Guernsey, III - Managing Member, Hexagon Software LLC
A new discussion of how structure, behavior, data, and information relate in the database world.

Free Seminar: Data Structure Metamorphism - May 8, 2008 (repost)

Wed, 30 Apr 2008 09:11:34 +0000

We've obtained a venue on Seattle's west side:
Data Structure Metamorphism: Controlled Emergence of Database Design
hosted by The Seattle XP User Group.

Free Seminar: Data Structure Metamorphism - May 8, 2008 (repost)

Wed, 30 Apr 2008 09:11:34 +0000

We've obtained a venue on Seattle's west side:
Data Structure Metamorphism: Controlled Emergence of Database Design
hosted by The Seattle XP User Group.

The Courses News channel is now open!

Wed, 30 Apr 2008 08:44:44 +0000

This is where we will post notices of upcoming courses and seminars.

The Courses News channel is now open!

Wed, 30 Apr 2008 08:44:44 +0000

This is where we will post notices of upcoming courses and seminars.

Common Components SDK v1.6.0 now available.

Wed, 16 Apr 2008 04:32:16 +0000

Common Components SDK v1.6.0 can be downloaded. The graph-building piece has been upgraded to support "forwarding" and a new block of functionality has been added to support dynamic rule ordering.

Free Seminar: Data Structure Metamorphism - May 8, 2008

Mon, 14 Apr 2008 20:18:33 +0000

We've obtained a venue on Seattle's west side:
Data Structure Metamorphism: Controlled Emergence of Database Design
hosted by The Seattle XP User Group.

Free Seminar: Data Structure Metamorphism - April 24, 2008

Sat, 05 Apr 2008 21:22:45 +0000

The response to our last free seminar was so positive, we decided to do it again with a new name:
Data Structure Metamorphism: Controlled Emergence of Database Design
hosted by Net Objectives.

Part V: Collaboration

Fri, 28 Mar 2008 10:25:15 +0000

By Max Guernsey, III - Managing Member, Hexagon Software LLC
A discussion of how the need for collaboration doesn't change between Agile software and databases.

Refactoring Data - March 25th, 2008: Success!

Thu, 27 Mar 2008 00:08:10 +0000

We had approximately fifty-percent attendance and a very positive response.
As promised, we have made the slides available in PDF format.

Update: Refactoring Data - March 25, 2008

Thu, 20 Mar 2008 23:14:48 +0000

This is an update on a previous post. The new deadline to RSVP is 3-24-2008.

Part IV: Change

Sat, 08 Mar 2008 22:46:29 +0000

by Max Guernsey, III - Managing Member, Hexagon Software LLC
Ruminations on the nature of change in the database world as opposed to in the software world.

Part III: Testing

Fri, 29 Feb 2008 19:03:31 +0000

By Max Guernsey, III - Managing Member, Hexagon Software LLC
We consider how current testing practices apply to the database world.

Free Seminar: Refactoring Data - March 25, 2008

Thu, 28 Feb 2008 18:16:34 +0000

Hexagon Software is proud to announce its first free seminar:
Refactoring Data: Mitigating the Risks of Structural Changes
hosted by Net Objectives.

Part II: Builds & Deployment

Mon, 25 Feb 2008 17:48:21 +0000

By Max Guernsey, III - Managing Member, Hexagon Software LLC
Here we talk about how we should think of database creation. Many of us currently think of it as an operational concern. This can lead to a number of stumbling blocks when attempting to introduce agility...

Part I: Evolution

Sat, 23 Feb 2008 11:57:11 +0000

By Max Guernsey, III - Managing Member, Hexagon Software LLC
In this installment we discuss what I think is one of the most central and least portable practices: evolutionary development. Why is this so important? It's the practice that let's designs emerge. Without the ability to change our design for the better, we have to plan for every kind of variation; if not every variant. Why does it not work with data? Simple: databases don’t evolve.

A New Series: Rethinking Agility in Databases

Sat, 23 Feb 2008 03:29:29 +0000

Author: Max Guernsey, III - Managing Member, Hexagon Software LLC
We cannot simply reapply the Agile practices we have developed for software development to databases. Instead, we need to reduce these practices to their essence - the principles which underly them. From those principles, we can then rebuild practices for databases.

DataLink SDK v0.2.0 now available.

Mon, 18 Feb 2008 05:44:50 +0000

DataLink v0.2.0 is released and now available for download. This is the beginning of a new product.

DataLink SDK v0.1.0 now available.

Tue, 12 Feb 2008 09:20:04 +0000

DataLink v0.1.0 is released and now available for download. This is the beginning of a new product.

License Enforcement SDK v1.5.0 now available.

Mon, 11 Feb 2008 11:34:48 +0000

The License Enforcement SDK v1.5.0 has been released and is available for download.

DataConstructor SDK v1.5.1 now available.

Mon, 11 Feb 2008 11:34:26 +0000

DataConstructor v1.5.1 is released and now available. This version is based on Common Components 1.5.1 and installs assemblies into the GAC.

ALERT: Windows Vista Security Issue With Install Package

Mon, 11 Feb 2008 06:31:54 +0000

It has come to our attention that Windows Vista security changes make it difficult for some customers to install our products.

License Enforcement SDK v1.4.0 now available.

Mon, 11 Feb 2008 06:31:47 +0000

The License Enforcement SDK v1.4.0 has been released and is available for download.

The Basics of Test Driven Database Design

Mon, 11 Feb 2008 06:30:42 +0000

Author: Max Guernsey, III
The basics of test-driven development for databases. It does not directly reference Hexagon Software DataConstructor but everything it discusses can be achieved with DataConstructor.

DataConstructor SDK v1.5.0 now available.

Mon, 11 Feb 2008 06:30:37 +0000

DataConstructor v1.5.0 is released and now available. This version represents a significant leap forward.

DataConstructor SDK v1.4.0 now available.

Mon, 11 Feb 2008 06:30:34 +0000

DataConstructor v1.4.0 is released and now available. This version represents a significant leap forward.

Immutable, Self-Referential Graphs: Why & How

Mon, 11 Feb 2008 06:27:38 +0000

Author: Max Guernsey, III
This entry explains why immutability is important, even in self-referential graphs, and demonstrates how it can be achieved using Hexagon Software Common Components.

Common Components SDK v1.5.1 now available.

Mon, 11 Feb 2008 06:27:33 +0000

Common Components SDK v1.5.1 can be downloaded. It has been upgraded to depend on Bootstrap 1.4.0 and the installer places assemblies in the GAC.

Common Components SDK v1.5.0 now available.

Mon, 11 Feb 2008 06:27:31 +0000

Common Components SDK v1.5.0 can be downloaded. It comes with an expanded set of Reference implementations and a new object-lease-management framework.

Common Components SDK v1.4.0 now available.

Mon, 11 Feb 2008 06:27:28 +0000

Common Components SDK v1.4.0 can be downloaded. It introduces a few new features in the same vane as ChainObjectProcessorBuilder.

Bootstrap SDK v1.4.0 now available.

Mon, 11 Feb 2008 06:25:41 +0000

Bootstrap SDK v1.4.0 has been released.

We now have a Resources page

Sun, 30 Dec 2007 23:33:00 +0000

We now have a page linking to other services and resources that we think promote Lean and Agile programming.

DataConstructor SDK v1.3.0 now available.

Sat, 29 Dec 2007 23:28:00 +0000

DataConstructor v1.3.0 is released and now available. This version is signed with our code-signing certificate.
This version of DataConstructor is also based on version 1.3.0 or later of License Enforcement, Common Components, et al.

License Enforcement SDK v1.3.0 now available.

Sat, 29 Dec 2007 22:59:00 +0000

The License Enforcement SDK v1.3.0 has been released and is available for download.

Common Components SDK v1.3.2 now available.

Sat, 29 Dec 2007 22:44:00 +0000

Common Components SDK v1.3.2 can be downloaded.

The DataConstructor News channel is now open!

Thu, 27 Dec 2007 17:31:00 +0000

You've found the source for the latest DataConstructor news and alerts.
Check this page on a regular basis, if you're interested in releases, features, or product updates.

Common Components SDK v1.3.0 now available.

Sat, 22 Dec 2007 21:19:00 +0000

Common Components SDK v1.3.0 has been released. It contains three new features:
1. Support for immutable object-graphs with circular references
2. Strategy objects that can easily be extended by composition
3. Advanced XML serialization

Bootstrap SDK v1.3.0 now available.

Tue, 18 Dec 2007 19:29:00 +0000

Bootstrap SDK v1.3.0 has been released.

VSGlue SDK v1.3.0 now available.

Tue, 18 Dec 2007 18:26:00 +0000

VSGlue SDK v1.3.0 has been released.

Bootstrap SDK v1.0.3 now available.

Thu, 06 Dec 2007 19:36:00 +0000

Bootstrap SDK v1.0.3 has been released.

VSGlue SDK v1.0.3 now available.

Tue, 04 Dec 2007 11:02:00 +0000

VSGlue SDK v1.0.3 has been released.

Coming Soon: Inventory Liquidator.

Sun, 02 Dec 2007 06:11:00 +0000

Soon we will be releasing a new application called "Inventory Liquidator."

The Applications News channel is now open!

Sun, 02 Dec 2007 04:01:00 +0000

An introduction to the Applications news channel.