Mind Like a Sword

The Three Laws of Test-Driven Development are Useful but Incomplete

noreply@blogger.com (Burk Hufnagel) — Wed, 26 Apr 2023 03:18:00 +0000

While out on a walk in early 2021, I was thinking about the best way of teaching Test-Driven Development (TDD) to other developers when I realized something unsettling: Robert C. Martin’s “Three Laws of TDD” are incomplete. I had read about the three laws in a blog post of his many years earlier and found the idea intriguing enough that I tried using them for a while. The results were good enough that I made them part of my TDD practice, and I shared them with others when teaching a TDD workshop or giving a presentation on it.

Once I realized the Three Laws were incomplete, I became concerned that even though I had benefited from following them, the people I shared them with might not be getting the same results. Not because I was a better developer, but because I had been practicing TDD for a couple of years when I read about the Three Laws and when I tried following them, the habits I had already built filled in the gaps -- which I suspect is also why I didn’t notice the Laws were incomplete at the time.

So, what’s missing from the Three Laws and why do I think my version is better? Before I show you my version, let’s start with a reminder. Uncle Bob’s Three Laws go something like this :

You only write production code when there is a failing test.
You write just enough test code for it to fail or fail to compile.
You write just enough production code to make the failing test pass.

If you compare this description with the three steps of TDD (often referred to as Red, Green, Refactor) you’ll notice that the Three Laws have you moving from Red to Green then back to Red over and over. Though I didn't notice it at first, there is no mention of Refactoring, which is the third step of TDD. Refactoring the code is necessary so we can clean up any mess made while writing the test or production code and make them easier to understand and modify.

The other problem I saw is that the Three Laws don’t address the two most common questions developers new to TDD ask; “How do I know what tests to write?” and “How do I know when I’m done?” While you could argue that these questions have nothing to do with the process of TDD, I think that calling them the “Three Laws of TDD” implies they’re all you need to know to do TDD.

In any case, I have a zeroth rule that answers the question and, I think, makes the whole thing complete. So, here’s my version of the Rules for succeeding with TDD:

Burk’s Rules for Test-Drive Development

0) You only write a test to describe an unmet requirement.

1) You write just enough test code to fail, and not being runnable counts as failing.

2) You write just enough production code to make the test runnable.

3) When the completed test fails for the expected reason, you write just enough production code to make it pass.

4) You refactor the production and test code to clean up any mess.

The zeroth rule answers the questions about knowing what tests to write and knowing when you’re done. It also connects TDD with the system requirements, which means we don’t have to guess about what tests to write and how we know when we’re done.

Once I had developed my solution, I submitted a talk on it to The Developer Conference since their Call-For-Papers was open. The talk was accepted, and I presented it there in June 2021. About six or seven months later, Uncle Bob’s book “Clean Craftsmanship” was published, and I bought a copy. While reading it, I was surprised and pleased to see that in addition to the Three Laws, he briefly mentioned that there was a Fourth Law - and that it was to Refactor. I don’t know whether he had heard about my talk or not, but I’m glad we agree that refactoring is a critical step to making TDD work.

If you find this useful and/or thought-provoking then please share it with other developers.

Burk on Books: Growing Object-Oriented Software, Guided by Tests

noreply@blogger.com (Burk Hufnagel) — Mon, 27 Feb 2012 13:59:00 +0000

If you want the short version, here it is: Developers should get this book and spend some time absorbing the ideas in it. It’s well written and easy to read, but grokking it all will take time and practice. I recommend doing it as a team, book club style; read a bit then discuss it so you can bounce ideas off each other and get the benefit of other viewpoint. I also recommend starting now so you can write better code sooner!

Note to those who care: ‘Grok’ is a real word now, it’s in the Oxford English Dictionary, though I prefer the definition in Merriam Webster’s.

Still here? Well then, I think it’s safe to assume one or more of the following; you weren’t convinced by my four sentence review, you want more details about the book, or maybe you’ve just got some time to kill and like my writing style. Hey, stop laughing, it’s possible...

According to the authors, “Growing Object-Oriented Software, Guided by Tests” is the results of a couple of decades of experience, including almost ten years of Test-Driven Development (TDD) on a wide range of projects. While the authors state that the goal of the book is to teach you TDD, don’t believe them. From what I read, the goal is to teach you TDD the way it should be done. Just as having 100% code coverage doesn’t mean there are no bugs, writing unit tests first doesn’t guarantee a working system.

The authors expand upon the traditional approach to TDD by adding acceptance tests to the mix. Acceptance tests, sometimes called end-to-end tests, begin at the user level (UI or public API) and exercise all parts of the system to ensure the system performs correctly.

Their approach adds an outer loop to the standard Red-Green-Refactor cycle. The loop starts with writing a failing acceptance test then writing all the unit tests needed to make it pass. While it may seem to be a small thing, I think adding the outer loop gives needed direction to the developers’ efforts by highlighting what should be built next.

The book starts with a quick introduction to the authors’ view of TDD, the tools that will be used in the examples throughout the book (JUnit 4, the Hamcrest matching framework, and the jMock2 Framework).

In Part II, the authors go deeper into how they start a project using their acceptance test/unit tests approach. In it, they introduce the concept of a “walking skeleton” which forms the basic structure the rest of the system is built upon.

Part III, a “Worked Example” is the longest section of the book, and it’s where we get to look over the authors’ shoulders as they build a nontrivial application that includes a Swing-based user interface and third-party services in the back-end. Even so, it’s not a realistic application, which is good because at the level of detail they’re giving us, the book would be too big to lift.

One of the most important things this book does is prove that you can test-drive a functional user interface. Yes, it’s a Swing-base UI, but I suspect you could follow the same approach using Seleium or Geb and test-drive a web-based UI too.

Part IV is titled “Sustainable Test-Driven Development” and it the authors present some useful guidelines intended to help you keep your sanity while maintaining a test-driven approach.

Part V covers “Advanced Topics” like how to test persistence, dealing with mult-threading, and how to test asynchronous code.

There’s more after that, including “A Brief History of Mock Objects” and two useful Appendices.

I said it before, and I’ll say it again. Developers should get this book and spend time absorbing the ideas in it; preferably with other team members for the most benefit, Go solo if you must, the time invested will be well spent.

Disclosure: I received a free copy of the book from the publisher, with the understanding that I would read it and write a review of it. For more information read my Full Disclosure post.

Here's the publishing details:

Title: Growing Software , Guided by Tests

Authors: Steve Freeman and Nat Pryce

Published: 2009 by Addison-Wesley

ISBN-10: 0321503627

ISBN-13: 978-0321503626

Full Disclosure on Book Reviews

noreply@blogger.com (Burk Hufnagel) — Sat, 18 Feb 2012 13:56:00 +0000

It seems I may have some housekeeping to do so please read this posting so you'll know what to expect from my book reviews.

Some time in 2009, the FTC published guides governing endorsements and testimonials that may apply to me. While I do buy some books and review them, most of the reviews I post are for books I have received from the publisher with the expectation that I would read the book and post a review. Please note that I said "a review" and not "a positive review".

If you read my reviews, you'll notice that they're all pretty positive. There are multiple reasons for that, but I want to make it clear that other than the book being reviewed, I do not receive any kind of compensation from any of the publishers, or anyone associated with them, in exchange for a positive review. Note that I have, on occasion, asked for copies of a book to give away when doing a presentation at a developer conference. I don't see that as compensation because it doesn't benefit me so much as the people who get the free books.

There are two main reason my books reviews are positive is simple. The first is that I'm not vain enough to believe that if I don't like a book then it must be a bad book. The second reason is because before I ask for a review copy, I do some research. I'll look for the book on Amazon or Safari, or even in a real book store, and read a bit. If it looks interesting and I like the style then I'll ask the publisher for a review copy.

If I'm reviewing a book that's just come out then it's likely I've either read a previous book by the author, it's part of a series (like Head First) that's earned my trust, or it's a topic (like automated testing) that I'm deeply interested in and am willing to take a chance on the unknown.

In case you're wondering, I tend to like books that are technical without being dry. The author should present the information in a way that doesn't make me feel like they're looking down on me because I don't already understand whatever they've spent a decade mastering. Good examples include Presentation Zen, PragProg books like Pragmatic Thinking and Learning, and anything in the Head First series published by O'Reilly.

By the way, Addison Wesley sent me some books that are definitely top notch. I just posted a review for "Essential Skills for the Agile Developer", I'm writing the review for "Growing Object-Oriented Software, Guided by Tests", and I'm reading "12 Essential Skills for Software Architects".

Setting up all those links reminds me, while I often provide links to Amazon, or a publisher's site, so you can easily buy the book being reviewed. They are for your convenience only. I don't get credited or compensated for purchases made by folks using those links.

In the spirit of full disclosure let me say that I once requested a book from a publisher and, after reading it, realized I couldn't give it a positive review. The book was a certification guide, but there were so many factual problems that I knew I could not recommend it to anyone. Instead I emailed the publisher a rather long list of the errors I found, let them know I could not publish a positive review, and offered to send the book back.

So, that's the story. Many of the books I review are sent to me at no cost, but with the expectation that I will read them and post my honest opinion. Some of them are books I bought and wanted to share with you. In either case the opinions I post are mine and are as objective as any opinion can be.

Burk on Books - Essential Skills for the Agile Developer: A Guide to Better Programming and Design

noreply@blogger.com (Burk Hufnagel) — Tue, 14 Feb 2012 13:59:00 +0000

“Essential Skills" is a part of Net Objectives' Lean-Agile series. The authors’ intent is to teach the "minimal set of skills developers need on the journey toward becoming adept at incremental development.” In my opinion they’ve more than met that goal.

Note that while the title says "Agile Developer", almost all the examples are in Java, and the skills are just as useful to Java developers as to any other kind.

Due to its focus on the fundamentals of good software development, “Essential Skills” is one of those rare books that is valuable to both beginners and experienced developers.

Beginners will learn to develop high quality software, while experienced developers will be reminded of valuable practices they may have dropped while attempting to meet aggressive deadlines. But there's more.

The authors also describe the benefits gained, which is quite useful if you're often asked to "cut corners" and deliver something sooner. (Imagine flashes of lightning and ominous music here.) Once business people see how rushing things out the door leads to lower code quality, and eventually results in longer deliver times, they tend to back off a bit.

You've no doubt heard that moving a team that produces so-so software to an agile process won't improve the quality. They'll just produce it faster. However, using the skills you learn from this book will increase the quality of your software. And, over time, you may notice that it's sped things up too - whether you go agile or not.

In short, I strongly recommend this book for both beginning and experienced developers, no matter what methodology you follow. I found myself nodding in agreement more than a few times as I read, and I think you will too.

Oh, yes. One more thing. If you do nothing else, find someplace to read the Preface. Yes, that's right, the Preface. It's only two pages, but there's something worth learning right there. If you're not sitting in a bookstore, you can get it straight from the publisher at InformIT. If the link doesn't work, just go to http://safari.informit.com/9780321700469 then click the link for the Preface and enjoy.

“Essential Skills for the Agile Developer: A Guide to Better Programming and Design”
Authors: Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky
Publisher: Addison-Wesley Professional; 1st edition (August 29, 2011)
ISBN-10: 0321543734 ISBN-13: 978-0321543738

JavaOne 2010

noreply@blogger.com (Burk Hufnagel) — Sun, 26 Sep 2010 03:40:00 +0000

JavaOne 2010 is officially over but for me it's still going on. I had the opportunity to give a technical presentation and lead a BOF (Bird Of a Feather) talk as well. PDF files of the slides for both are posted on the Oracle OpenWorld, JavaOne, and Oracle Develop On Demand web site. As far as I know, you must have attended one of the three conferences to have access, so I'm looking at posting the files to GitHub too. I'll update this post with the URL once they're up there. I'll post more about JavaOne after I've had a chance to catch up on my sleep.

I got back Friday morning around 6:00 AM, crashed for a couple hours, then got in line for registration at the No Fluff Just Stuff Software Symposium. It starts at noon on Friday and ends around 8:00PM; then goes all day Saturday and Sunday.

Normally, I stay for the dinner and KeyNote on Friday but not this time. My friend Charlie and I missed the dinner and keynote so we could attend a special Google Technology User Group meeting where Josh Marinacci of the Palm Developer Relations team talked about (and demo'd) cross-device mobile app development. Josh was involved with Swing and JavaFX before leaving Sun, and now he's with HP evangelizing the WebOS platform and cross platform development. He's scary smart and very passionate about user interfaces and user experience and I'm already looking forward to the next opportunity I have to see him present.

Needless to say, this has been a long week. Very fun with lots of opportunities to meet interesting people, sharpen my skills, and learn about new technologies and processes - but I wouldn't recommend making a habit of it.

If you were at JavaOne - especially if you attended one of my sessions - please take a moment to leave a comment. Same goes for you NFJS folks and GTUG members.

Next week's shaping up to be busy too and I expect I'll be posting something about the Big Texas Android BBQ about ten days from now.

Over. (That means it's your turn to talk - or in this case post a comment.)

Burk on Books - 97 Things Every Programmer Should Know

noreply@blogger.com (Burk Hufnagel) — Fri, 05 Feb 2010 14:00:00 +0000

A little less than a year ago I told you about "97 Things Every Software Architect Should Know," a ground-breaking book O'Reilly had just published. I was very excited about the book for two reasons. The first is that the contents were contributed by experts from around the world under the Creative Commons Attribution 3.0 license, which means it's kind of an open source book. The second thing is that I wrote two of the 97 things chosen to be in the book.

If you read that post then you might share my feeling of deja-vu when I tell you that in a couple of weeks O'Reilly will publish a new "97 Things" book. This one is titled "97 Things Every Programmer Should Know" and once again I wrote two of the 97 things appearing in the book.

I'm hoping that programmers of all stripes will find the contents useful and interesting enough that it outsells the first book. If you'd like to take a sneak peek at the articles, they're available at the O'Reilly web site's 97 Things wiki.

If you like what you find there, please consider buying the book. No, I'm not suggesting you buy the book because I'm looking for a big royalty check. Remember the Creative Commons License I told you about? The only "payment" a contributing author gets is a free copy of the book. I want to boost sales for three reasons:

I think most developers will find it a valuable resource.
I think that good book sales will encourage O'Reilly to keep adding books to the series
I've got an idea for a 97 Things book I want to see in print.

If you do read the articles, please leave a comment here or send me an email. I'd love to hear from you.

Thanks for your time and attention,

Burk Hufnagel

Questions and Answers: O'Reilly's got both

noreply@blogger.com (Burk Hufnagel) — Wed, 04 Nov 2009 14:00:00 +0000

As of today there's a new place to go when you have questions (or answers) about pretty much anything you think is interesting. With the tag line "Clever Hacks, Creative Ideas, Innovative Solutions", answers.oreilly.com has set an expectation that this is the place to go when you need to know something that most folks don't have a clue about.

While O'Reilly has earned a reputation as a great source for technical information because of their books and their magazines (Make and Craft), that's not good enough for them. They've also built an online community and are expanding it with this latest addition. One neat difference between Answers and other Q&A places it that there's a section for sharing information that nobody's asked about yet. So if you know how to do something or solve a gnarly problem, you can preemptively post it there.

Recent entries (as of Nov 3, 2009) include information on SEO (Search Engine Optimization), file sharing between Mac OSX and Windows 7, HTML 5 and Palm's webOS, regular expressions, and Drupal. Like I said, lots of things most folks don't have a clue about.

So if you've got a tough question, know the answer to tough questions, or just want to share some of what you know without waiting to be asked, then head on over. It's free - though you do need an O'Reilly account to do anything more than look around. But even that is more than worth the time.

Oh yes, there's social aspects too. (After all Tim O'Reilly is "closely associated" with the term "Web 2.0".) You can make friends (Hi, Marsee!), build a reputation, and even earn badges for things like posting regularly, blogging, reviewing books (Huzzah!) or making lots of friends there.

It's still in beta, but I think you'll have a lot of fun and learn a thing or three so why not head on over now. The URL is http://answers.oreilly.com and it's open now!

After you've looked around there a bit, please consider coming back here and sharing your thoughts about O'Reilly's new addition to their community site.

P.S. Yes, I know there's way more links in this article than I usually use. I figured that it might make it easier for you to check out some of the things I'm writing about without being too pushy. Let me know what you think and it may affect how I do things in the future. Thanks!

Burk on Books - Groovy Recipes by Scott Davis

noreply@blogger.com (Burk Hufnagel) — Fri, 23 Oct 2009 13:02:00 +0000

Almost a year ago I read "Groovy Recipes" and posted my review on DZone in early November. I also wrote up a posting for this blog but it never got published. The good news is that the book is still relevant and worth picking up if you're interested in getting things done in Groovy.

I would like to say that I actually held off posting this note so that I could create a second wave of interest after the initial one faded, but that would be misleading so instead I'll just hope it works out that way.

Burk

P.S. Scott, if you're reading this, the fact that I'm finally posting this mere hours before you're speaking at the No Fluff Just Stuff conference I'm attending later today is a complete coincidence. Really.

Burk on Books - Switching to the Mac, Designing Web Interfaces, and Essential JavaFX

noreply@blogger.com (Burk Hufnagel) — Thu, 22 Oct 2009 13:02:00 +0000

Its been a while, but I've recently posted three new book reviews on DZone; Switching to the Mac and Designing Web Interfaces, and Essential JavaFX. While they cover very different topics, all of them are worth reading.

Essential JavaFX is a great introduction to JavaFX. You get a good feel for working with JavaFX without having to devote too many hours to it. The only thing I didn't like is that the images are gray-scale instead of color. I know it ups the printing cost, but when you're dealing with graphical user interfaces I think having color is important.

Switching to the Mac is a great book for those of us who have spent many years on Windows and finally move to a Macintosh. I bought mine almost a year ago and found that my previous training didn't help me on my Mac so I did what I often do. I went looking for a book to help me. After reading reviews of several books and leafing through a few at Borders, I decided on Switching to the Mac, and I'm glad I did. It's not the kind of book I read cover to cover, but it's stuffed with useful information. If you moving like I did, I think you'll find if useful to keep the book near your Mac for a while.

Designing Web Interfaces is an excellent book for anyone designing web applications. It's well written with plenty of color diagrams and screen shots (Yes!) so you can see how various interactions play out. I am a little disappointed though because there's no sample code even though the authors say they targeted the book for designers and developers. Even so, I think this is a great book for designers and a good one for developers who enjoy a challenge.

That's it for today. I've got three more reviews to write up, one book to read and review, and I think I'll be caught up.

BTW, I'll be at the the No Fluff Just Stuff software symposium here in Atlanta this weekend so if you're there and want to talk about the books, or any aspect of software development, feel free to introduce yourself.

One more thing before I sign off, this blog isn't intended to be a one way signal. If you want to ask a question or share a thought (preferably one that is relevant to the posting), please leave a comment.

Burk on Books - Pragmatic Thinking and Learning

noreply@blogger.com (Burk Hufnagel) — Fri, 24 Apr 2009 13:00:00 +0000

Last year, Andy Hunt (co-author of the Pragmatic Programmer) authored a new book titled “Pragmatic Thinking and Learning: Refactor Your Wetware”, and I’d like to tell you a bit about it.

It’s a great book. You should stop reading this blog posting and go buy a copy of the book, then sit down and read it. Now.

OK. That was the short version, which is probably all that some of you needed to hear. The rest of this is for people who are looking for some details.

The book is published by the Pragmatic Bookshelf, it was released on October 28th, the ISBN is 1934356050, it retails for $34.95 and is worth every penny. Still not enough? OK, I’ve got a detailed review posted on DZone in the IT Book Zone (at http://books.dzone.com/reviews/pragmatic-thinking-learning) and you can win yourself a free copy if you read the review, post a comment, and get chosen by the Fickle Finger of Fate.

If you’re still reading this, I’m guessing that you’re looking for some insight that’s not in my other review. OK, here goes: The secret to getting the most out of the book is that you can’t just read it. Andy’s put exercises in the book and you need to do them, and do them the way it’s described, to get the most out of it. This isn’t much of a secret because Andy tells you the same thing early on in the book, and in a podcast (“Andy Hunt on Pragmatic Wetware") which is available on the PragProg.com website or from ITunes. The reason I bring this point up is that it is very easy to know this and somehow still not do it.

The other secret is that reading the book (and doing the exercises) is still not enough. Just like Neal Ford’s book “The Productive Programmer”, you need to actually practice the things you read about. It’s not enough to think, “Cool! I love that idea!” Until you take action, and begin practicing what you’ve read about, you won’t really benefit from knowing it.

As someone more profound than I once said, “Those who do not read are no better off than those who cannot” or, more succinctly, “To know and not do is not to know.”

Thus endeth the day's lesson.

Burk on Books - Practical API Design

noreply@blogger.com (Burk Hufnagel) — Tue, 31 Mar 2009 13:00:00 +0000

Practical API Design: Confessions of a Java Framework Architect

Author: Jaroslav Tulach

Published by: Apress on July, 2008

ISBN: 1430209739

If you write code then you are designing APIs and this book is for you.

Jaroslav Tulach, is the founder and initial architect of NetBeans and in this book he shares with us the lessons he learned during ten years of designing APIs that are used by developers around the world.

If others use your APIs, then the lessons found here are worth far more than the price of the book and the time it takes to read and digest it. Do yourself, and your users, a favor and start studying it today. And if others don’t use your APIs, then it might be that you need this book even more.

“Practical API Design” is divided into three parts: In part one, Jaroslav describes the theories underlying his approach to API design and his reasons for writing “another design book.” This section is reasonably brief and introduces the main concepts underpinning the rest of the book. In part two Jaroslav draws on his decade of experience and expounds on what works and what to avoid when designing frameworks and APIs for public consumption. Part three is where the rubber meets the road and Jaroslav shows how the theories and ideas from part one can be applied in daily life to achieve the practical application of the rules as described in part two.

The information in this book is relevant to every developer, though I will admit that some probably need it more than others. If you write code, you’re creating APIs - even if you’re the only one using them. If you’re creating APIs then knowing how to create and evolve those APIs benefits you and anyone who depends on those APIs to get things done.

For me, the bottom line on this book is that anyone who writes code winds up creating APIs, so it makes sense to learn how to create, evolve, and maintain them without breaking any code that already uses them.

There are some nice resources out there for anyone interested in learning more about this book. Here are just a few:

Jaroslav has created a website at “http://wiki.apidesign.org/wiki/Main_Page” with the intent of building a community around the book and the ideas he’s expressed in it.

Download chapter 1 from Apress at “http://www.apress.com/book/view/9781430209737”.

Check out InfoQ's interview with Jaroslav Tulach at “http://www.infoq.com/articles/tulach-practical-api-design”. In it there's a link to download chapter 3.

If you’re interested in learning more about the book, I have a more detailed review on DZone (and I’m told they may be giving away a copy) at http://books.dzone.com/reviews/practical-api-design.

Happy reading!

Burk Hufnagel

ITARC 20009 was a great success!

noreply@blogger.com (Burk Hufnagel) — Tue, 17 Mar 2009 13:00:00 +0000

The Atlanta, GA edition of ITARC 2009 was held a couple of weeks ago and, based on the feedback I got from attendees and my own experience, it was a great success. Over 150 architects and people interested in becoming an architect spent two days in a beautiful environment (Thank you, IBM!), with good food, and learning from each other's experiences as well.

But the best thing was the wide variety of talks available, and the quality of the speakers (including Grady Booch via second life) who gave them. As a member of the chapter hosting the conference, and one of the speakers, I may be biased. But, I was able to attend a number of the talks and not only did I learn a good bit, but I found the speakers to interesting, well informed, and worth listening to.

The bottom line is that this year's ITARC was great and that you should make every effort to attend next year's Atlanta ITARC. For those of you not familiar with it, ITARC is short for "IT Architect Regional Conference"; so there may be one coming to your area later this year. I do know there's one scheduled for New York in late September, and you can always check the IASA home page for more information.

For any of you wondering about my talk, I'd say it went very well. The room was set up for 24 people but another eight or nine showed up and wound up standing in the back, so the attendance was excellent. During the talk itself, people looked interested and asked some questions, and the feedback I received from IASA indicted that the attendees enjoyed it and thought it was well done.

Mini Java puzzler - Zapped by static

noreply@blogger.com (Burk Hufnagel) — Mon, 16 Mar 2009 23:50:00 +0000

I was modifying some legacy code (defined as code with no automated tests) and found something unexpected when I tried to use it. The original code was rather complicated (possibly because there were no tests), but this simplified version has the same odd behavior:

public class Test {
    static {
        initName();
    }

    static String name = "Sue";
    static Test instance = new Test();

    public static String getName() {
        return name;
    }

    private static void initName() {
        name = "Bond, James Bond";
    }

    public static void main(String[] args) {
        System.out.println("My name is " +
                Test.getName() + ".");
    }
}

So we have a class with one static variable, three static methods and one static initializer. Other than the static initializer, it looks like a pretty simple class that's easy to understand doesn’t it?

In case you’re not familiar with static initializers, let me paraphrase a bit of Sun’s Java Tutorial: "A static initialization block is a normal block of code enclosed in braces, { }, and preceded by the static keyword. They can appear anywhere in the class body, and the Java runtime guarantees they are called in the order in which they appear in the source code."

That sounds kind of cool, but what’s the point? Why would you use one? Well, a static initializer executes when the class is loaded into memory and it is normally used to do some kind of one-time processing for the class. In this case, the initializer calls the initName() method when the Test class gets loaded into memory and before it’s main method executes.

So, getting back to the puzzle, the question is this: What does the above code do when you run the class?

Here are the possible answers:
   A) It prints “My name is Sue.”
   B) It prints “My name is Bond, James Bond.”
   C) Nothing, because it doesn’t compile.
   D) None of the above.

I recommend taking some time to figure out your own answer before reading any further. You’ll get more out of this is you do. Don’t worry, I’ll don’t mind the wait.

Ready to look at the answers? Good. First things first. Answer C, "Nothing, because it doesn't compile" is not correct. I included it just so I can tell you that I don’t like that kind of answer on a puzzle, or Java certification exam for that matter. Any IDE worth using will tell you if the code will compile or not. While it may have been a useful skill years a go, when our only tools were stone knives and bearskins, we’ve had better tools for so long now that it seems unreasonable to ask a question where “it won’t compile” is the right answer. OK, back to the puzzle.

What about answer B? Well, if you’ve attended one of Josh Bloch’s Java Puzzlers talks (or read my earlier Mini Puzzler), you know the whole point of this is to show you code that looks simple but behaves strangely. So you probably didn’t pick answer B - even though it looks like that’s exactly what should happen. And you would be right in doing so. The code doesn’t print “My name is Bond, James Bond.”

What about the ever popular “None of the above.” Sorry, not this time. Answer D is not correct either.

By the process of elimination, the correct answer must be A. It prints “My name is Sue.” and, as it turns out, that is just what does happen. Don't trust me on this, run it yourself - then come back for the explanation.

When I ran the original test code, I didn’t believe the results. It didn’t make any sense so I ran it in the debugger. If you do the same, you can see that the initName() method does get called before the main() method, and that when initName() finishes, the value of “name” is “Bond, James Bond” - just as we expected.

So what’s going on? How does “name” get set to “Sue”? Well, to mis-quote the spirit of Obi-Wan, “Use the source, Luke.”

In looking at the source, you can see that right after the static initializer, we’re declaring and initializing the “name” variable. Which seems odd because the initName() method already set “name” to a value - so it must already exist, right?

Sort of. The compiler sets aside space for the variable and includes code to initialize it but, because “name” is a static variable, its initialization happens when the class is loaded into memory instead of when the class constructor is called. It also appears that, like a static initializer, static variable initialization also happens “in the order in which it appears in the source code.” So after the static initializer is called, the code that initializes “name” to “Sue” executes and overwrites the value we expected to see. Believe it, or not.

So, how do we fix it? Simple. Swap the two lines so the variable is declared and initialized before the static initializer block gets called. Actually, there’s an even better solution for this kind of situation. Since the static initializer is only determining the value for one variable, have the line that declares the variable call a private static method that returns the variable’s initial value. Doing so would’ve prevented this problem in the first place, and ensures that nobody can accidently re-order the lines and start wondering why they’re seeing a line from a Johnny Cash song instead of something Sean Connery ought to be saying.

If you’ve got any feedback on this please post a comment.

Thanks for reading,
Burk

DevNexus 2009 review

noreply@blogger.com (Burk Hufnagel) — Sun, 15 Mar 2009 16:06:00 +0000

DevNexus is the new name for the Atlanta Java DevCon conference, which is organized and hosted by volunteers from the Atlanta Java User Group (AJUG). The conference was recently re-branded as DevNexus because it's not limited to Java anymore. Don't get me wrong, Java is still a major focus, but there are other languages (some of which run on the JVM) and technologies that AJUG members use and we wanted to include those too.

DevNexus has expanded to two days this year and may be even bigger next year. Not only that, but it went from two tracks to three, so there were even more tempting talks to choose from.

Speakers ranged from Neal Ford (Meme-Wrangler at ThoughtWorks, well known NFJS speaker, and author of The Productive Programmer) to Emmanuel Bernard (lead developer at JBoss, and spec lead for JSR 303: Bean Validation), to Peter Higgins (project lead for the Dojo toolkit) and Doris Chen and Justin Bolter (Technology Evangelists from Sun); and the topics were just as varied.

After some introductory remarks from Burr Sutter (Java Champion and AJUG top-dog), Neal Ford got the ball rolling Tuesday with his keynote "On the lam from the Furniture Police," which was an excellent look at how to be productive in a corporate environment that seems designed to prevent it. Neal's excellent keynote was followed by four hours of technical break out session on topics like Test Driven Design (not Development), browser optimization (aka getting around browser restrictions), grid computing, and how to create and use RESTful web-services with Java. The official day ended with Emmanuel Bernard's keynote on "Scaling Hibernate" which also gave us a look at some of the new features Hibernate supports, like sharding and full text search capability. After that, there was a "cocktail reception" for people who preferred a friendly chat (sometimes called networking) with other developers and architects over sitting in rush-hour traffic.

Wednesday got off to an interesting start. Doris Chen and Justin Bolter gave their keynote speech titled "JavaFX: The Platform for Rich Internet Applications" which, not surprisingly, promoted JavaFX as the best solution for Java developers who want to build RIAs. This was followed by Yakov Fain's keynote, "Picking the right technology for Rich Internet Applications" which compared Adobe's Flex, Microsoft's Silverlight, and JavaFX. During the speech he stated his belief that JavaFX might be a contender in 2010, but not today. I found this a little disconcerting, having just heard about what JavaFX can do. While I'm not sure I agree with him, I do think Yakov made some good points, though things may change with the release of JavaFX 2.0 slated for later this year. In case you're interested, his recommendation for developers that need to start an RIA project today was to use Flex.

After the clash of the RIA titans, there were three hours of breakouts mostly geared toward RIA or web development; topics included JavaFX, Java and Flex, developing modular Web applications using Spring 3.0, and GWT. There were also some server-side topics like a JEE 6 preview, a look at Spring 3.0, JSecurity also known as Apache's project 'Ki', anda look at JVM-based dynamic languages in the enterprise.

The conference ended with a rap-session hosted by Burr Sutter, AJUG's main leader and Java Champion, asking for ways to improve the conference next year and how we can get the word out about it so more people will attend. There were several good suggestions, and you've just read part of my solution to the question.

DevNexus was a great conference and well worth the cost (just $185 for the whole thing) so start planning to attend next year; you'll be happy you did. BTW, the price is set so that the costs of the conference are just about covered; this is not a 'for profit' venture, it's part of the way that AJUG works to build the Atlanta Java community. If you want to get involved, start attending the monthly meetings (they're free) and see what you've been missing out on.

If you were there, or wished you were, and have something you'd like to share then please leave a comment.

Thanks for your attention,

Burk

97 Things Every Software Architect Should Know hits #1 at Amazon

noreply@blogger.com (Burk Hufnagel) — Mon, 02 Mar 2009 14:00:00 +0000

A few days ago, I shared with you my joy about a new book titled "97 Things Every Software Architect Should Know" which I co-authored with 52 other architects .

Even though it's only been available for a couple of weeks, the book is doing very well. In fact, Amazon's sales ranking currently shows it at #7 in Software Development, and #1 in Design & Architecture. It's also #1 in Surveying & Photogrammetry, but I think that's because the tags include the word "architect".

(Note: If you click on the slightly blurry image below, the link will show you the actual image from Amazon.com in all its glory.)

Burk In Books: 97 Things Every Software Architect Should Know

noreply@blogger.com (Burk Hufnagel) — Wed, 25 Feb 2009 01:36:00 +0000

There's a new book available from O'Reilly titled "97 Things Every Software Architect Should Know: Collective Wisdom from the Experts" and though I'm very excited about it, I won't be reviewing it here. Actually, I'd like to post a review, but you probably would not trust it because I'm one of the "experts" who's "wisdom" was collected for the book.

The book is primarily a series of short articles on various topics that software architects deal with in the real world. All of the articles were contributed under the Creative Commons, Attribution 3, license - which means it's essentially an open source book. In fact, the 97 articles in the book are available online for free at the 97 Things web site. O'Reilly also has a preview available on their website so you can see the cover and what the articles look like in the actual book - unfortunately, my articles are toward the end of the book and the preview stops much earlier.

I recommend going to the web site and reading an article or three. If you like it consider buying a copy of the book. I say that not because I get royalties - I don't. Nor did I get paid for the initial writing. I'm suggesting you buy one or more copies because I want the book to succeed so O'Reilly will be encouraged to do more books in the same style; collecting contributions from community members who have something interesting to say and making them available.

The whole process of trying to come up with useful bits of information and explain them in an interesting way - before somebody else beat you to it was fun and challenging and I'd like to do it again. So please go take a look then come back and let me know what you think of it.

{Note to self: Come up with a good sign off line.} <- Yes I meant to leave that there. It's motivational. Burk

Windows XP running slower than usual

noreply@blogger.com (Burk Hufnagel) — Tue, 24 Feb 2009 14:24:00 +0000

If you've noticed that your XP box isn't as perky as it usually is, this post may be just what you need.

This morning I was running a build that normally takes about seven minutes, but when I checked on it - expecting to see everything had compiled properly - I found it had hardly begun. What the...? So I pulled up the Windows Task Manager, I saw that instead of using 20 to 50% of the CPU, the java.exe (we use ant so it shows up as java.exe and not javac.exe) process was putting along at single digits with an occasional sprint up to 16%.

Looking at the list of running Processes, I noticed a few I didn't recognize. Since this is a company box, I wasn't too surprised but I figured I'd do a little research on what was out there. As it turns out, I hit a homer with the first thing I looked up - a little beastie named cidaemon.exe.

Turns out it's used by an Indexing service from our friends at Microsoft and it had somehow gotten turned on. When I Googled the name I found this page on Microsoft's Help and Support site which told me how to turn it off. I followed the instructions and suddenly java.exe was back to it's normal (relatively) speedy self.

If you're seeing a similar problem on your XP box, bring up the Task Manager, click on the Processes tab and look for something called "cidaemon.exe" under the Image Name column. Note: If the items aren't in alphabetical order you can click on the Image Names label and they will be.

If cidaemon.exe is out there don't just click the End Process button to kill it, or the next time you reboot it will be back. Instead follow these instructions from Microsoft and you'll be set.

That's all for now, I've got some code to write.

I'm speaking at ITARC 2009!

noreply@blogger.com (Burk Hufnagel) — Fri, 13 Feb 2009 13:00:00 +0000

Just letting you know that I am speaking at this year's ITARC 2009 in Atlanta, GA which is a software conference put on by the International Association of Software Architects also known as IASA. For more information about the IASA, take a look at their website.

I'll be speaking about the importance of User Experience design, why we, as architects, need to be familiar with it, and how to improve the user experience of the software we design. The talk itself is scheduled for Friday, February 27th from 11:20 - 12:20 and the title is "The Layperson's Guilde to Building Better User Experiences.

If you'd like to learn more, take a look at the agenda. Or, better yet, just register for the conference and experience it for yourself!

Mini Java Puzzler

noreply@blogger.com (Burk Hufnagel) — Thu, 12 Feb 2009 17:47:00 +0000

I was working on a project and needed to get a Long value from a String. I know the Long class (like the other wrapper classes for primitives) has static methods that do just the thing , so I started typing in my IDE and trusted that I’d find one that worked. As it turns out there are several methods that do similar conversions. Here’s a list of the candidates:

 Long.decode(String nm)
 Long.getLong(String nm)
 Long.parseLong(String nm)
 Long.valueOf(String nm)

So, given that each of these takes a String and returns a Long, what does the following code return? (Notice that the getLongValue() method returns a primitive long:

    public long getLongValue() {
      Long value = Long.getLong("23");
      return value.longValue();
  }

Here’s the list of possible answers:

 A) 23L
 B) 0L (zero)
 C) It depends.

Before you continue reading, what do you think the right answer is… OK, that’s enough thinking. Let’s take a look at the possible answers and see what seems likely.

Now it seems reasonable that Long’s getLong() method should return the value of the String as a Long, so answer ‘A’ looks pretty good. Then again, if it were that easy why would I bother posting this. Answer ‘B’ doesn’t seem very reasonable - unless getLong() isn’t really converting the value of the String. So that leaves answer ‘C’ as the primary suspect. If you’re familiar with Josh Bloch’s Java Puzzler talks from JavaOne, you’ll probably go with ‘C’ because it is kind of vague and that makes it a safe bet.

And you’d be right. The correct answer is ‘C’.

It turns out that Long.getLong() doesn’t try to convert the value of the passed in String directly. It looks for a System property with that name, retrieves the value associated with it, and converts that. So what the getLongValue() method returns depends on the value of the System property “23″. So, what if there is no System property “23″? In that case, the method throws a null pointer exception because Long.getLong() will return a null. Ouch!

I found this the hard way. I needed to convert a String and picked a likely method from the list provided by my IDE. I was greatly surprised when my unit test failed, so I looked up the JavaDoc on it and realized my mistake.

There are a few morals to this story:

   Unit tests are your friends.
 Use the JavaDoc, and make sure you write some
    for people using your code.
 Hurrying can cause unexpected delays; but those
    can become fodder for a blog post.

Until next time, I leave you with the traditional Java Puzzler farewell,
“Don’t code like my brother.”

Burk on Books: Inside Steve's Brain

noreply@blogger.com (Burk Hufnagel) — Sun, 18 Jan 2009 18:33:00 +0000

Inside Steve’s Brain by Leander Kahney
Published by Portfolio (the Penguin Group) in April 2008
ISBN: 591841984

“Inside Steve’s Brain” by Leander Kahney is a nice little read (7.2 x 5.4 inches and under 300 pages) that is both entertaining and educational. The Steve in the title is, of course, Steve Jobs and the book provides a look into how he thinks about things like leadership, user experience, product design, and teamwork.

The introduction describes parts of Jobs’ career and private life. The next six chapters focus on his personality traits and how they impact the way he (and Apple) works. The last two chapters describe how it all comes together and enables Apple to do things other companies seem to find difficult to emulate.

Each chapter ends with a list of “Lessons from Steve” and while we may not have the ability to follow all of them ( “Partner only with A-players and fire bozos” – who wouldn’t love to do this!) they are still worth remembering. The book includes a case study of how it all came together with the iPod, and ends with a look at why Jobs (and by extension, Apple) keeps producing closed systems (think iPod, or Mac) while the rest of the industry produces open systems that allow the user to plug in third party hardware. While this is controversial, it does make sense from a certain point of view; doing so allows Apple a tighter integration between the hardware and software, which means a more pleasant user experience with both.

The book is interesting and thought-provoking. Whether or not you are a fan of Steve Jobs and Apple, you must admire the loyalty of their customers base; they must be doing something right. Any of us should be thrilled if our customers felt the same about us. So maybe it’s worth spending a little time exploring the territory “Inside Steve’s Brain.”

P.S. You an go to a page on the book's website (http://insidestevesbrain.com/thebook.html) and see a three minute video of the author talking about the book. Or better yet, download the Introduction and see if it appeals to you before you buy the book.

Learning Java by Leading

noreply@blogger.com (Burk Hufnagel) — Thu, 06 Nov 2008 14:02:00 +0000

Another great way to keep up your technical skills is to lead a certification study group. They say that the best way to learn something is to teach it. While that may be true, I can tell you that you don’t have to teach. I’ve recently found that leading a study group grants many of the same benefits while giving you an out. Since you’re just leading the group, and not actually teaching the topic, you don’t have to be an expert.

Even better, if someone in the group really is an expert on part of the topic, or just knows more about it than you do, you can defer to their expertise without losing credibility. And, that’s a win for everybody. (On the other hand, when I lead a group, I think it is important for me to know as much as possible about the topic so I can answer most of the questions they bring up.)

Certification itself seems to be a controversial topic, but I think that most people would agree that it is a way for interested people to learn more about a given topic. Personally, I think studying for certification is great because it forces me to learn about things I wouldn’t otherwise be too familiar with. For example, way back in 2001 I was studying for the Sun Certified Java Programmer (SCJP) exam (version 1.2 I think) so I had to become familiar with the Java IO classes. While they're useful for working with directories and files, I had no experience with them because at the time I was writing code that ran in an app server.

As I stated above I’m currently leading a study group and we're preparing for the SCJP exam for Java 6. While reading this week's chapter, I ran into something possibly useful and definitely interesting. Like the Java I/O classed in 2001, it's something new to me because I’m mostly writing JEE code and most JEE app servers don't support Java 6 yet. Sigh.

Anyway, we’re using Kathy Sierra and Bert Bates’ “Sun Certified Programmer for Java 6 Study Guide” as our text. It's an excellent book and since Kathy and Bert were instrumental in writing the exam, I figure that after working our way through it we should be covered. This week we’re on chapter 6 which is all about Strings, I/O, Formatting, and Parsing.

The I/O section introduces the java.io.Console class, which is new in Java 6 and lets you read from and write to the command line – if the environment you’re running in supports it. You write information to the console by calling format() and printf(), and you read from it using readLine() and readPassword(). The readLine() method is for retrieving a single line of text from the console. The readPassword() method also retrieves a line of text, but doesn’t echo it to the screen so your password isn’t displayed - which seems reasonable. So far so good, right?

Now comes the interesting bit. The readLine() method returns a String, but the readPassword() method returns a character array. After I read that, I looked up and wondered why the API wasn't consistent. It seemed to me that it would be better if both of them returned a String. Then my eye caught the next sentence and suddenly it all made sense.

Since readPassword() returns a character array, you can do whatever validation is necessary and then overwrite the data with something else to scrub the password from memory. So, why can’t you do the same thing with a String? Think about it for a bit before you read the next paragraph…

That’s right! In Java, Strings are immutable and they’re stored in a special memory pool so the JVM can reuse them; which means that if readPassword() returned a String then the confidential information you took pains to hide from prying eyes could be found by someone sifting through the system’s memory.

Of course, this also means that once you get the password you should take pains not to do anything that would create a String out of it; but you probably figured that out already.

If you're in a study group, or leading one, please leave a comment and let me know what you think about it. Is it valuable? Is it a waste of your time? And what do you think about Java certifications? Are they intrinsically valuable, or does it depend on circumstances?

Thanks for reading this. Y'all come back now, y'hear?

Beating the odds by reading books

noreply@blogger.com (Burk Hufnagel) — Mon, 03 Nov 2008 03:38:00 +0000

In my copious spare time (gained by not watching much TV) I read and review books, technical and otherwise, as a way of keeping up with the rest of the world. (You can read my most recent review here.) Usually I’m working on one or two books at a time (did I mention I love to read?) but I discovered some really interesting books in a short period and now I’ve gotten a little swamped. At this point, I’m reading three books and writing reviews for three others.

I posted one review to DZone.com’s Book Zone last Friday, but you won’t see it in their listing until the zone leader approves it. The other two are not technically technical (they aren’t specifically about programming or software development per se) but they are books I would recommend to developers and architects who need to communicate their ideas with others.

The review I posted is for “Groovy Recipes” by Scott Davis and it is a book I highly recommend for anyone interested in the Groovy programming language. As its title suggests, the book is full of recipes showing you how to get something useful done in Groovy. There’s even a section with recipes for Groovy’s web framework, Grails.

If you’re looking for a new language to learn, or you’d like to improve your skills with Groovy, this is an excellent choice to help you on your way.

“Presentation Zen” is the name of a web site as well as a book, both by Garr Reynolds. I found the web site when I was working on a technical session for JavaOne 2008. While I loved the approach Garr suggested, I was pretty sure I couldn’t pull it off in the time I had left to prepare. I stuck a more traditional approach and swore to myself that I would come back and learn to improve my presentation skills.

This book is full of good information and can point you in the right direction, but you (and I) have to do the work needed to improve - reading alone probably won't cut it. But, if you want to get better at presenting information then this is a great place to start.

The third review I’m writing is for a wonderful little book titled, “The Back of the Napkin” and it’s subtitle “Solving problems and selling ideas with pictures” pretty much lets you know what to expect when you read it. If you’re anything like me and most of the programmers and architects I’ve worked with then you’re probably comfortable sketching a diagram to describe a problem or solution to the people you work with. So why would you want to buy a book about it?

Well, take a look at the website Dan Roam (the author) set up for the book and watch the video on the five focusing questions and the six ways to see and show. That should be enough to get you to place an order for the book today. In case the site’s down or you can’t view the videos, the point is that Dan presents a well reasoned method to figuring out how to visually solve problems and present the solution to other people so they can understand it. From my point of view, getting better at those two things is well worth the price of the book and the time it takes to read it, and you can’t ask for much more than that.

I’ll update this post – or just post a short notice – when the reviews are done and out there. I also post to the Atlanta Java User Groups’ Book Corner so you may see them there first.

Oh yes, the title of this post is my way of thumbing my nose at the "statistic" I've heard concerning the average number of books a programmer reads in a year - which is supposedly zero. I don't know about you, but I'm doing my best to boost that number; and learning a good bit at the same time...

Dang. I just realized I'm going to need a good sign-off phrase to let you know I’m done and didn’t just hit the “post article” button by accident.

A Weekend full of Learning

noreply@blogger.com (Burk Hufnagel) — Wed, 29 Oct 2008 13:00:00 +0000

Where do you find people who willingly spend their entire weekend learning about things like Java class loaders, Groovy, Java Server Faces, Google Web Toolkit, Test Driven Development, Alternative languages for the JVM, and other similar topics? Well, last weekend you’d have found about two hundred of them at the 2008 Greater Atlanta Software Symposium put on by No Fluff Just Stuff.

The conference started Friday at 1PM and ended Sunday at 6PM, with breaks for food and sleep. The primary draw was twelve 90-minute opportunities to learn about one of 72 topics being presented by some of the best speakers out there including people like David Geary, Scott Davis, Neal Ford, and Ted Neward.

And if that weren’t enough (Is it ever?), each day had an extra goody; on Friday Jared Richardson presented a potentially life-changing keynote titled "Career 2.0" (keep an eye out for the book), Saturday ended with a choice of BOFs, and Sunday's lunch was followed by an hour-long “expert panel” featuring seven of the speakers holding forth on topics like architecture, testing and SOA.

If you’ve never heard of No Fluff Just Stuff then you’re in for a treat. It’s kind of like a traveling, three-day long, JavaOne. I recommend checking out their web site for a time and place when they’re either someplace near you or someplace you want to visit, then sign up and get ready to learn. It's good for your career.

What's in a name?

noreply@blogger.com (Burk Hufnagel) — Sat, 25 Oct 2008 00:07:00 +0000

Listening to Jared Richardson speak, I knew I had to make a change and I needed to do it tonight. Jared was tonight's key note speaker at the "Greater Atlanta Software Symposium" aka No Fluff Just Stuff. His talk was titled "Career 2.0," and it got me thinking (again) about my career and what I want to do and be.

Jared made a lot of suggestions, and I intend to give some of them a try. One of the many things he suggested was to become a blogger because it's an easy way to share the things we learn with others. He said it's easy to create a blog. In fact, he claimed that it is so easy to get started that on previous occasions some people had actually fired up their laptops and created a blogging account during the second part of his speech.

After I got home I decided to take part of Jared's advice and enter the blogosphere. I went to blogger.com's home page and, since it only required three steps to get started; create an account, name the blog, and pick a template. I have to admit that it did look pretty easy.

I created an account, but then I had to wonder about the folks Jared spoke about. Creating the account was easy, but picking a name was definitely not. I'll admit that it took me a while, partly because all the names I initially wanted were taken; but it's also because I believe names are more important than you may think.

I suggest to you that names conjure images in our minds and can affect both our expectations and behaviors. Let me give you an example.

Many years ago my neighbors had a dog named "Rambo." Care to guess what kind of dog it was? If you've seen the "Rambo" movies, starring Sylvester Stallone, you'd probably thinking that Rambo was a powerful dog with a serious attitude; something like a Rottweiler; and you'd be partly right.

Rambo did have an attitude, but he wasn't big at all. You see, Rambo was a toy poodle. (Yes, I asked about the name. It turns out that when they decided to get a dog, my neighbors had a tough time deciding, so they compromised. She got to pick the dog, but he got to name it.) The point is that we often have preconceived ideas about people and things based on their name, and I wanted to pick a name that would help people get in the right frame of mind for what I was expecting to post here.

The first name I picked that hadn't already been used was "Musashi Flex" and I wrote much of this post for that blog's initial posting. But the next day I found that explaining what the Musashi Flex was, and how it applied to my blog,was more work than it was worth; though fans of Steve Perry's Matador series, it might have grokked it.

So I went back to thinking up a meaningful name and, after sleeping on it, the phrase "mind like a sword" is what I've come up with. It's not the perfect title, but I like it and I like the idea of equating mental sharpness with a sword's effectiveness in battle. (Yes. I am familiar with the phrase "Just like a(n) X to bring a knife to a gunfight", where X is some group you don't want to ba associated with; but "Mind like a bullet" just isn't me.)

I expect to do a few things with this blog:

Share my ideas on software development.
Share issues and solutions I run into while working as a software architect and developer.
Provide a place to discuss and review some of the many of the books I read - most, but not all, related to software design and development.

Well, this seems like a reasonable length for my first post. Thank you for your time and attention.

May you live long and prosper!