Erik on Software

New Book Review: "Team Geek"

New book review for Team Geek: A Software Developer's Guide to Working Well with Others, by Brian W. Fitzpatrick and Ben Collins-Sussman, O'Reilly, 2012, reposted here:

Arguably the best text on the software development process that focuses on the individual contributor within the context of a team. When I initially discovered this text, I was wary whether it would have anything to offer, and if so, whether it would cater to new development staff or seasoned professionals, but after a reading I am convinced that Fitzpatrick and Collins-Sussman have something to offer regardless of technical career stage, and even offer significant insights to managers who are willing to learn.

After discussing the myth of the genius software developer, the authors present their thoughts on a healthy team culture, followed by discussions on effective team leadership, working with difficult people, using organizational manipulation to get things done effectively, and user engagement. At first glance, the discussion on user engagement might seem out of place, but my consulting experience has shown that this aspect of the software development process is important, and the authors tie it in very well.

The best part of this text is that Fitzpatrick and Collins-Sussman, both at Google at the time of writing this book (they have worked with each other at three jobs, and also written three books together), simply tell it like it is, and offer no fluff. Some of the topics that the authors touch are not really found anywhere else to any significant degree, and I hope that a signficant portion of the software development profession has a chance to read what they have to offer at some point in the near future.

Judging by the number and distribution of dog ears resultant from my reading of this text, the strength of the content is consistent throughout, unlike many other texts in this genre which tend to offer good content up-front, but then taper off over the course of the second half. While the reward for this quality will result in this book sitting alongside the best of the best on my bookshelf, it also adds difficulty to the review process, because I do not have the space for a "The New Yorker" magazine review here, so I offer a few quotes that will hopefully increase potential reader interest.

In Chapter 1 ("The Myth of the Genius Programmer"), the authors recount their speaking engagements over the past six years, and point out the distinctive trend in the types of requests they were getting for Google's open source Project Hosting service, which revolved around hiding specific code branches, hiding new open source projects until they are ready to be seen, and deleting code version history.

"The key motif here is insecurity. People are afraid of others seeing and judging their work in progress. In one sense, it's just a part of human nature - nobody likes to be criticized, especially for things that aren't finished. This attitude tipped us off to a trend within software development. Insecurity is actually the symptom of a larger problem." The resultant discussion then leads to their presentation on the foundation that all healthy interaction and collaboration is based (humility, respect, and trust), and point out the following important maxim: "Don't equate your self-worth with your code quality."

In Chapter 2 ("Building an Awesome Team Culture"), the authors discuss an important aspect that is all too often ignored in books of this genre: team culture. "Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people. Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone. In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture."

In their discussion of the team leader in Chapter 3 ("Every Boat Needs a Captain"), the authors address risk in their presentation of team leader as catalyst. "Risk is a fascinating thing - most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs. As a result of this, the usual modus operandi is to work conservatively and focus on smaller successes even when taking a bigger risk might mean exponentially greater success."

"One thing we often say at Google is that if you try to achieve an impossible goal, there's a good chance you'll fail, but if you fail trying to achive the impossible, you'll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete. A good way to build a culture where risk taking is accepted is to let your team know it's OK to fail."

Chapter 5 ("The Art of Organizational Manipulation") contains one of the many important take-aways from this book. "As an engineer, try to focus your energies on launching products over just about everything else. Shipping things gives you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you've accomplished something."

"As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we've learned from experience that if you dedicate more than half of your time to this kind of defensive work, it's hardly valued at all and you'll find yourself in the somewhat embarrassing position of having nothing (politically) important to show for your time. This is not only a good way to get no recognition, but it's also a good way to get your product canceled."

Liquibase in the Enterprise: Part 5

A year has gone by since I last posted about Liquibase, an open source database change management tool that I exclaimed is "one of the best software development tools I have used in recent years" in my first post of the series. All of these posts continue to remain some of the most visited pages on my blog, so when I was recently contacted by a startup that is looking to potentially commercialize Liquibase, I thought my readers would be interested in hearing about it.

In my opinion, this is an exciting development in the history of Liquibase. Recently contacting me via LinkedIn, the cofounder and CTO of the firm indicated that he was currently going through the "market validation" process of commericializing Liquibase. What is market validation? Essentially, it is assessing the marketplace to reduce risks associated with the offering of a new product.

And what do I mean by open source commercialization? Almost four years ago, I wrote a blog post on this subject for the now defunct thought leadership area of my consulting employer website that I recently reposted. I noted the following: "If you have not yet noticed, a fair number of open source software products have been acquired by commercial firms, and much open source has the backing of commercial entities, which has a number of implications, including the fact that when the choice of one of these products is made, one often has the choice whether to obtain support for a fee."

According to the individual who contacted me about Liquibase, with whom I exchanged emails and eventually spoke, other than my blog, the only other site he thought was worth mentioning on the subject of Liquibase is the one posted for IBM developerWorks by Paul Duvall. This particular post was made over four years ago, so the validity of the content may no longer be correct, but it does provide a good sense of what the tool is all about.

The startup is looking to potentially build a wrapper around Liquibase that will provide additional administrative features and other product features that will add to the functionality and ease of use of the software, while still retaining the integrity of the original code so that it can remain version agnostic as the open source version continues to release new versions on its end.

The individual mentioned that although he realizes there are some smart individuals in the development community such as myself who have no need for such repackaging, they see a need to do so in order to appeal to a wider user base. And of course, if there were nothing different with the commercialized version, the adoption rate would probably not increase. There are nuances with Liquibase that can only be discovered through usage, so it makes sense that some of these are worked out in an automated way transparent to the developer.

In providing a very high level overview of the two major projects on which I used Liquibase for clients, which you can read about in my earlier posts, it was interesting that the individual who contacted me wanted me to concentrate on the first of the two when answering his dozen or so market validation questions. Perhaps it was because of the nature of the project (creating a new enterprise database versus reverse engineering for virtualization), the specific database product (DB2 versus Oracle) for which I used Liquibase, or the development environment and team culture (larger versus smaller team, although I led both in an agile manner).

Market validation questions were additionally centered around the size of the technical staff at each client, the nature of each development project (custom software or heavy use of COTS), the level of SQL skills amongst developers, the development methodology used, the maturity of our release processes, as well as pain points with regard to database change management. In addition, I was asked a number of questions on technical subjects related to the project, and how they related in terms of impact.

The conversation was a very interesting experience. For confidentiality, I am intentionally ambiguous with regard to the clients and the startup that are the focus of this blog post, even though it has not been explicitly requested of me not to disclose this information. Looking back to one of my first jobs after undergrad, disclosing my client at the time was strictly verboten, so in the years since I have typically stuck to this practice for practical reasons.

---

Liquibase in the Enterprise: Part 1

Liquibase in the Enterprise: Part 2

Liquibase in the Enterprise: Part 3

Liquibase in the Enterprise: Part 4

Commercialized Open Source (Repost from January 2009)

One nontrivial area of decision making that is of increasing import in recent years involves the choice between open source and commercial products.  If you have not yet noticed, a fair number of open source software products have been acquired by commercial firms, and much open source has the backing of commercial entities, which has a number of implications, including the fact that when the choice of one of these products is made, one often has the choice whether to obtain support for a fee.

As architect for a recent client, for example, I was able to help sell the use of JBoss Application Server (JBossAS) as a low-cost alternative to more costly commercial Java EE application server packages, primarily due to the available support of the product by its recent acquirer, Red Hat.  While development of a full Java EE compliant product was under way by the firm, with a planned version 5.0.0 release, a series of smaller releases were made available after Red Hat involvement and before this Java EE release was made available earlier this month.

After version 4.2.0 of JBossAS, when Red Hat made its purchase, the JBoss website was transformed and a quick makeover of user and technical manuals began.  While the content changes between the open source and commercial versions of the JBoss line of products are debatable (the two versions are still kept separate), some of the disclosure that was made available during this transition phase was new.  For example, strong warnings against production use of the embedded JBoss database, Hypersonic, were suddenly included in JBossAS documentation.  Discussions with fellow colleagues confirmed that such warnings were a new development.

There are likely trade-offs with any architectural decision.  Open source software can be a very viable alternative to commercial products, especially when community support of open source is high.  In addition, many technology innovations appear in open source before their commercial counterparts (and many commercial products are now embedding open source, such as Apache HTTP Server, into their products), and depending on the technical abilities of open source adoptees, costs can be much lower (and in the case of JBossAS, much of the available technical talent is already familiar with the product since it has grown to be the most highly deployed Java EE application server).  And with JBossAS as an example, more readily available, thorough documentation can sometimes be the result of commercial involvement, although this is not necessarily the case.

MySQL, an open source relational database product, was also acquired by a commercial entity, Sun, this past year.  Whether MySQL is a viable alternative to commercial relational database products is open to debate.  However, what is apparent at this point in time is that corporate adoption of MySQL has steadily increased since its initial release, and Sun hopes to continue to transform the product in a space that is shared by database heavyweights such as Oracle and IBM.

This past week, Computerworld magazine reported that MySQL co-founder Michael Widenius advised users to be “very cautious” about recently-released version 5.1.GA of MySQL due to a number of serious bugs that the release still exhibits.  It is interesting to hear Widenius quote Marten Mickos, Senior Vice President of Sun’s Database Group, who apparently said that “MySQL version 5.1 will be released as GA in or before December [2008] because I say so“.  The original blog entry by Widenius also declares that MySQL version 5.0 was also released too early.  Now, it does need to be pointed out that Widenius toned down his message shortly after his blog entry, but attention to development team communication by open source groups that is often not readily available from commercial counterparts is an important responsibility of the architect.

New Book Review: "Portlets in Action"

New book review for Portlets in Action, by Ashish Sarin, Manning Publications, 2011, reposted here:

In just having recently completed a development project creating portlets for the first time with a Java Portlet Specification 2.0 (JSR 286) compliant portal server, I hope I can provide some insight into the effectiveness of this book, since I used it to hit the ground running. Simply put, I agree with some of the other reviews here that this book is very well put together. The progression of content that the author provides from one chapter to the next is effective for those newly tackling portal development. As a consultant in such a situation, I especially appreciated Chapter 1 ("Introducing Portals and Portlets"), Chapter 2 ("The Portlet Lifecycle"), Chapter 3 ("Portlet 2.0 API: Portlet Objects and Container-runtime Options"), Chapter 6 ("Using the Portlet Tag Library"), Chapter 7 ("Getting Started with Spring Portlet MVC"), and Chapter 11 ("Communicating with Other Portlets"). The UML sequence diagrams that the author provides greatly aided the material. And believe it or not, even at almost 600-pages the author even thankfully left out the fluff that one can unfortunately often expect in other developer texts of this genre.

That said, however, potential readers need to be aware of what this book does and does not provide. Unless the reader is using Liferay, the most frequently referenced portal server in this book, they should not expect to be able to get up to speed with any specific portal server. My target portal server, for example, was IBM WebSphere Portal 6.1.0, and this specific portal server is only mentioned in passing a few times by the author. Usage of the XML Configuration Interface, commonly known as XMLAccess, for example, which is a requirement when using the portal server in my project environment, was not covered. Personalization rules and managing portal pages was also not covered. As with other Java specifications, much is left up to implementers with regard to what is under the covers, but as with application servers, portal servers also provide features that sit outside these specifications. While I did not purchase this text expecting that the WebSphere implementation would be covered, as a novice in this space I also was not aware how much I would be dependent on product specific features. Well recommended guide and reference for those new to portal development, especially with Spring Portlet MVC.

HAPI Announcement: Version 2.0 Released

Earlier this week, version 2.0 of my favorite open source health care software framework was released, and I received the following email for the announcement:

Hi Everyone,

Today marks a big milestone for HAPI, with the release of version 2.0 of both the HAPI Java API and the HAPI TestPanel (well, technically it was yesterday, but we had some issues with syncing this release to the central Maven repo).

The new release comes packed with tons of bugfixes, plenty of new features, and improvements. See the Changelog for information on everything that is new in the API, and the TestPanel Changelog for changes there.

One thing to note: Migrating to the new version of the Java API should be very straightforward, but there is one notable difference to watch out for: As of version 2.0 the logging abstraction layer has changes from commons-logging to SLF4J, so you will need to include the SLf4J API JAR on your classpath. You will probably want to include an adaptor to an underlying logging framework as well. Maven users can copy the updated POM dependency snippets from here. Non-Maven users will find the new requirements in the "hapi-all" bundle on the Download area.

Thanks to everyone who contributed! In particular, this release features a huge set of contributions from Christian Ohr, who cleaned up a lot of old codebase, modernized the SimpleServer, and replaced the logging framework. We also had all kinds of useful contributions from all over the world over the last year. It's great to see how the HAPI community continues to gain traction after a decade!

Cheers,

James

This announcement was preceded by another email a couple weeks prior, in the spirit of what good quality open source software is all about.

Hi Everyone,

Just a quick note that it looks like we are ready to tag and release HAPI 2.0. I'd like to first ask if anyone is aware of any showstopper issues they feel we be addressing prior to this release.

I have to say, I"m very excited to see this release going out, as it is absolutely packed with new features from a great number of contributors! UHN has been using it internally for a few months now, and it looks rock solid.

Cheers,
James

Jump Start Your App: Sometimes Creativity Comes from Chaos

The article entitled "Appsurd: In Silicon Valley, It's Hard to Make a Joke" published in the Wall Street Journal this past week (June 5, 2012) immediately reminded me of the book "Jump Start Your Brain", by Doug Hall, that I read after receiving it as a gift shortly following its release date back in 1995.

Hall opens up Chapter 205, "Jumping the Tracks" by commenting that "All your life, you've been told to organize your thoughts. You've been taught to make your thoughts march like prisoners of war in tidy little regiments through your brain. Maybe it's time to disorganize."

"Organized thought leads to formula thinking. Corporations are very big on organized thought. In most large blue-blood corporations, it seems as if everything is based on precedent. All recommendations are couched in terms of how they compare to previous corporate experience."

"I have deep respect for tradition when it comes to proms, weddings, and world history. But tradition doesn't count for much when you're searching for wicked good ideas. Wicked good ideas happen when you break free from established channels of thought. They come from drawing outside the lines and going the wrong way down one-way streets."

"The brain naturally tends to operate in neat patterns and tracks. But creativity comes from chaos. Wicked good ideas don't surface through logical conscious process. They emerge through the ragged edge of the subconscious, like thieves in the night."

"The Jumping the Tracks programs are designed to force associations between seemingly unrelated aspects of a task. They offer practical steps for shedding the shackles of linear thinking. Some exercises rely on stimuli related to the problem at hand. Others use stimuli with little or no connection."

"The more a stimulus is related to the problem, the greater the chances of ending up with a great quantity of ideas. When the stimulus is unrelated to the subject matter, the ideas may be fewer but the potential for a major breakthrough is enhanced dramatically."

As I mentioned in my earlier review of this book, of the dozens of exercises that Hall presents, one of the simplest, Chapter 205's Brain Program #12, is one of my favorites. Essentially, using some dice, the objective of the exercise is to force-associate related elements of a problem in random sequence, increasing the number of connections that would not have been forged otherwise.

The Wall Street Journal article last week opens by stating that digital designer Alex Cornell's idea to create a spoof on Silicon Valley - "the most ridiculous possible app that no one would ever consider a real thing" - succeeded because even though he meant it as a joke, Silicon Valley took it seriously.

The app, called Jotley, is a rate-everything app that has attracted tens of thousands of users. Other apps sited in the article include:

• WhoDat.biz - "the Facebook of websites", "an innovative way to see who created any website"
• TacoCopter - "a service for delivering tacos with drone-like miniature helicopters"
• itsthisforthat.com - "generates often absurd capsule descriptions of internet start-ups by mashing up existing business concepts and buzzwords"
• Cloo - "lets urbanites market their bathrooms to nearby smartphone users in need"
• iPoo - "a social networking app that connects people sitting on toilets"

Although many of these apps have turned a profit - the article mentions that iPoo made enough money to put one of its creators through Harvard Business School - in discussing the history of Jotley, Cornell comments on perhaps one of the best reasons to make such apps: "One of our programmers said it would be fun to make, so we decided to crush it out."

New Book Review: "Hadoop in Action"

New book review for Hadoop in Action, by Chuck Lam, Manning Publications, 2010, reposted here:

After checking out reviews of what O'Reilly and Apress had to offer with regard to Hadoop, I ended up purchasing this book based on positive reviews, my past positive experiences with the Manning "In Action" series of texts in general, such as "Spring in Action" and "Java Persistence with Hibernate", formerly "Hibernate in Action" (see my reviews), and the fact that this book was the most recently published on the subject. In short, this text is well organized, and covers its focus on Hadoop well, but potential readers should be aware that about one-third of what Lam has to offer here are ancillary to Hadoop, and not with regard to Hadoop itself. Inclusion of the larger ecosystem within which Hadoop sits personally makes sense, and I do not think this aspect of the book detracts from what the author provides in any way.

The author provides a good introduction to Hadoop in the first three chapters, which includes a discussion on differences between Hadoop and traditional technologies in this space, such as relational databases, as well as a tour of Hadoop building blocks, working with files in the Hadoop Distributed File System (HDFS), and the anatomy of a MapReduce program. The next three chapters contain the bulk of the text, which focuses on writing MapReduce programs, and includes segments on chaining MapReduce jobs, joining data from different sources, creating a Bloom filter, and monitoring, debugging, and tuning.

The next two chapters offer a short cookbook in which the author presents 5 different general MapReduce techniques (Lam admits that specialized MapReduce techniques can be found rather easily by Googling, and that he does not intend this cookbook to be comprehensive in any way), as well as a chapter on managing Hadoop, followed by four chapters on running Hadoop in the cloud, brief introductions on programming with Pig (a Hadoop extension that provides a language called Pig Latin) and using Hive (a package built on top of Hadoop that provides a SQL-like language called HiveQL). and a chapter that discusses four Hadoop case studies from the New York Times, China Mobile, StumbleUpon, and IBM (the case study from IBM takes up about 50% of the discussion, and the case study from the New York times is less than a page).

Be aware that at the time of this review, this book was published over a year ago. One of the common complaints I read about what O'Reilly and Apress have to offer in this space is that their counterparts to this book cover older versions of Hadoop. In chapter 4, Lam mentions that "one of the main design goals driving toward Hadoop's major 1.0 release is a stable and extensible MapReduce API. As of this writing, version 0.20 is the latest release and is considered a bridge between the older API (that we use throughout this book) and this upcoming stable API. The 0.20 release supports the future API while maintaining backward-compatibility with the old one by marking it deprecated."

"Future releases after 0.20 will stop supporting the older API. As of this writing, we don't recommend jumping into the new API yet for a couple reasons: (1) Many of Hadoop's own library classes in 0.20 aren't written under the new API yet. You won't be able to use those classes if your MapReduce code uses the new API in 0.20. (2) Many still consider the most production-ready and stable version of Hadoop as of this writing to be 0.18.3. Some users are warming up to version 0.20, but we suggest you wait a little longer before going full production with it." The author follows up by writing that "by the time you read this the situation may be different. In this section we cover the changes the new API presents. Fortunately, almost all the changes affect only the basic MapReduce template. We rewrite the template under the new API to enable you to use it in the future."

Exactly two weeks ago today, Hadoop 1.0.1 was released after 6 years of development. Inbetween the version that this book covers, and this most recent version, several intermediary versions were released, which provide bug fixes, improvements, optimizations, and new features, as well as support for some of the offerings in the Hadoop ecosystem. More timely information on open source technologies that enjoy wide community support is always going to be more readily available on the internet, especially via blog posts, but in my opinion this fact does not detract from the value of this text, which still serves as a good introduction to the Hadoop ecosystem, especially for those more comfortable starting out with a published text. Just be aware that you will be quickly referring to other materials after you make your way through this text.

The portions that I especially appreciated about what Lam has to offer include his presentations in chapter 5 on reduce-side joining and creating a Bloom filter, the cookbook that he provides in chapter 7 that includes segments on passing job-specific parameters to tasks, probing for task-specific information, partitioning into multiple output files, inputting from and outputting to a database, and keeping all output in sorted order, as well as chapters 9, 10, 11, which discuss the larger Hadoop ecosystem, especially the introduction to Pig Latin. Recommended to anyone looking for an introduction to the Hapoop ecosystem of technologies who understands that published texts such as this one cannot contain information about the latest releases.

New Book Review: "Patent, Copyright & Trademark"

New book review for Patent, Copyright & Trademark: An Intellectual Property Desk Reference (11th Edition), by Attorney Richard Stim, NOLO, 2010, reposted here:

Good introduction to intellectual property law, which consists of four separate and overlapping legal disciplines: (1) patent law, (2) copyright law, (3) trademark law, and (4) trade secret law. Following an introduction that provides a high-level overview of intellectual property law, the remainder of the text is broken down into each of these disciplines, with the bulk dedicated to patent law and copyright law. Each of these sections provides an overview of the discipline covered, along with definitions associated with the corresponding discipline and explanations of forms that need to be filed, together with sample completed examples, followed by the actual legal statutes.

While the bulk of what Stim provides here is dedicated to patent law and copyright law, definitions are what carry this text across all of the four disciplines. That definitions comprise a majority of this text is important, because depending on the needs of the reader this may or may not be an effective format. This book is one of a number of self-help legal resources that Nolo provides, and so it is important to realize that this 600-page effort should probably be seen as just a good place to start one's journey in intellectual property. At the same time, it is also likely that the reader will not need to read this book cover-to-cover, because Nolo publishes separate texts dedicated to each of the four disciplines covered here.

Nolo has been updating this text regularly since the mid-1990s, so the reader can be assured that the content that is provided is up-to-date at time of publication. In each of the overview sections, Stim provides several pages under the header "What's new in patent law since the last edition?" that explain the major events in each respective discipline since the last edition of the book was published. In my opinion, this information mainly serves as a reminder that the law continues to evolve, and is probably best used by the reader as a starting point for further investigation, since the legal decisions provided are highly summarized. It is also worth pointing out that the author provides references to abundant web site resources that provide additional information.

The overviews and definitions are written clearly for those new to these legal disciplines. Compared to the last text I read on related subject matter, "Inventing Software: The Rise of 'Computer-Related' Patents" by Kenneth Nichols (see my review), I also find the material that this book provides to be very well organized. As a consultant in the software industry, the definitions that Stim provides for such terms as "algorithms", "software patents", "reverse engineering and trade secrets", and "software and trade secrets" are especially appreciated, and as a blog writer I also appreciated some of the tips that the author provides on copyrighted material. Recommended to anyone looking for an introductory text on intellectual property law.

Past Book Review (July 6, 2007): "Inventing Software"

 Past book review (i.e. posted prior to starting this blog) for Inventing Software: The Rise of "Computer-Related" Patents, by Kenneth Nichols, Quorum Books, 1998, reposted here:

From the first lines of the preface of this work by Kenneth Nichols, it is apparent that what was initially planned to be of more concise scope grew into a discussion of all things associated with software patents, and therein lies the rub. It is interesting that the author notes in just the second sentence that he "came to the conclusion that the particulars of the debate [within the programming community over the desirability and ultimate effect of software patents]...are not that interesting or enlightening". Really? I find it odd that an individual with a J.D. and an M.S. in Computer Science would make such a statement. Of course, his follow-up statement that the "larger and more important story" involves the fact that "software development is a new kind of creative activity, one that defies the neat and mutually exclusive categorizations of intellectual effort as either artistic or scientific" might be true, Frederick P. Brooks wrote extensively on this topic in his classic tome on software engineering long before the USPTO permitted the filing of related patents. Fortunately, Nichols dedicates most of his work to the more boring subject matter, although unfortunately the explanations provided are a bit boring themselves.

Putting aside the fact that this book was written in the late 1990s, however, there is a lot to offer here to the professional software engineer as well as the non-technical management community associated with software interests of this nature. For example, the author's concise 20-page introduction introduces well much of the background subject matter. Nichols also discusses well the topics of algorithms, programming, computer science, software engineering, and how patents fit in with this universe. The heart of the text, the third chapter which presents various software patent examples, however, is very poorly constructed in my opinion, although the explanation in its first few pages on major terms such as "novelty" and "nonobviousness" is concisely written. The diagram provided that depicts concepts related to nonobviousness, written in the style of a Venn diagram, is especially well suited for the discussion. The fourth chapter covers the software patent controversy, and the reader is well rewarded in my opinion when reaching this point in the book after 50 pages of rambling.

It is strange that the seventh chapter is dedicated to a definition of programming, a discussion best suited for the introductory pages of the book, although some of the quotes provided in these pages are quite entertaining, such as the W. Saba quote from an IEEE periodical that "hardware engineers have gone further than their software counterparts because hardware design became a science...Unlike hardware engineers, software engineers still deal in magic and witchcraft". Interestingly enough, it was just recently that The Economist discussed the emergence of computer science as the foundational branch of science. Last of all, while the sixth chapter boldly begins by proclaiming "we've finally come to the good part" because it deals with recommendations for software developers, only 6 pages are dedicated to the subject! If Nichols is to write further on software patents, I recommend an entire book dedicated to recommendations.

New Book Review: "Managing Time in Relational Databases"

New book review for Managing Time in Relational Databases: How to Design, Update and Query Temporal Data, by Tom Johnston and Randall Weis, Morgan Kaufmann, 2010, reposted here:

When this book was published last year, I must admit that the data architect in me was excited that an advanced database text had finally come along that addressed some issues that every data modeler must face (or should face) once they have mastered the rudimentary. The bulk of published database related books discuss SQL, or usage of specific database products. And while more books are beginning to appear on shelves that address topics such as data modeling, this genre is certainly in need of more texts that address the full spectrum of database usage.

Despite the weightiness of this 400-page effort, which required quite the journey (be forewarned), this book is one of the most painstakingly detailed technology efforts that I have read in quite some time that goes to great lengths in making sure the reader understands the material that is presented. No stones are left unturned along the way in the explanations of the authors on how to design, update, and query temporal data. In addition, the introductions that Johnston and Weis provide on temporal data management and asserted versioning in the first 150 pages are unrivaled in textbook publishing.

The authors state in their preface that there are four objectives of this book: (1) to describe how to manage uni-temporal and bi-temporal data in relational databases in such a way that they can be seamlessly accessed together with current data, (2) to describe how to encapsulate the complexities of uni-temporal and bi-temporal data management, (3) to explain how to implement temporal data management as an enterprise solution, and (4) to describe how to bring pending transactions into the production tables that are their targets, and how to retain posted transactions in those same tables.

The authors also note that as this book when to press, they started the process of converting their initial provisional patent application for Asserted Versioning into a patent application, although any non-software-vendor company is granted the right to develop its own temporal data management software based on the concepts presented in this book, as long as such software is for use only by the company and not sold, leased, licensed, or given away to any other company or individual. An implementation of the concepts presented by the authors, the Asserted Versioning Framework (AVF), is also being created by the authors.

Superb illustrations accompany explanations of concepts in all the right places. And the concluding chapter that the authors provide offers more substance than many lengthy white papers, offering an "ongoing research and development" section that presents a partial list of topics on which the authors are working, with topics such as use of AVF via Java and Hibernate of special interest to me. The asserted versioning glossary that spans over 50 pages of fine print and concludes the text is also highly appreciated. Well recommended to all data professionals.