I have rebooted this blog many times over the last several years. If you’ve been a reader of my blog in the past, you will have noticed significant changes. If you’re new here, welcome!

This reboot has been in the works for several months now, even though I’ve probably spent far less than 24 active hours working on it. Life as an “itinerant” consultant and conference speaker is extremely busy compared to what I was doing on May 16, 2012 (the date of my last blog posting). At that time I was in the middle of a transition from 3+ years as a front-line manager of a software development team into a lead software architect role. Since that time I’ve changed jobs (careers?) twice:

• June 2011 - February 2012: During this time I was titled as a “Technical Architect” at AutoZone’s corporate offices in Memphis, TN. My focus was the modernization of their retail store management system architecture and technical stack. While there I also did a fair amount of agile coaching.
• February 2012 - Present: In January, VMware came calling, wanting to know if I would join the vFabric Cloud Application Platform PSO as a Senior Consultant. After a few weeks of interviews and careful consideration, I made the jump. I’m now in the midst of helping a Fortune 50 company build a brand new “private cloud” hosting platform for their next generation of application development.

During that time I also significantly increased my participation on the No Fluff Just Stuff tour. In other words, I’ve BEEN BUSY.

At any rate, I have for quite awhile now wanted to get back into the practice of writing. However, I’ve wanted to do so outside the constraints of a hosted platform like Blogger or WordPress.com. Those systems place far too many constraints on how your blog works, and they also happen to be the only place that your data is housed. Sure, I could write my posts in Vim and then copy/paste them into the platform, but that’s annoying. I wanted to manage my writing using a plain text editor, mark it up using something lightweight like Markdown, check my writing into version control using Git, generate my site using a tool like Jekyll, and then push my site to the cloud. What was the easiest way to achieve all of this goodness? Octopress seemed to fit the bill.

So, what you now see is the result of my labor in migrating from WordPress.com to Octopress, hosted at Heroku. One day (perhaps) I’ll write up the process that I used. It was a bit convoluted and involved gigantic piles of yak hair, so I’d rather not consider that piece right now.

What I will be focusing on quite a bit is the idea of simplicity. For more than a decade I have wandered through the barren wasteland that is accidental complexity in software. A few months ago I viewed Rich Hickey’s keynote session at StrangeLoop 2011 entitled “Simple Made Easy”. It is Rich’s definition of simplicity in software that has inspired the brand new title of this blog, wherein I will chronicle my continuing quest to seek out simplicity in software structure.

Alas, it is time to return to billable work. I shall endeavor to post again in far less than a year. So, as we say in the south, “Ya’ll come back now, you hear?”

For those of you that don’t know, I recently returned to the technical ranks as a Software Architect after a three-year stint in management. To make a long story short, I now love my job again. Perhaps I’ll write the long story in a future blog entry. On to the topic at hand. Today I led the first significant design discussion that I have led in quite a long time. A few minutes afterward, I was already reflecting on what had occurred and how. The very first thing that I noticed was my drastically different approach to the task. I felt that my facilitation skills were more mature and effective than I remember from previous similar engagements. I’m not sure if the time I spent in management (where I facilitated quite a few meetings, though much more business-focused ones) helped, but something certainly has.

I also noticed several things that I’ll call “pattern vs. antipattern” tugs of war. Quite often during the meeting I felt the group trying to move our discussion in one direction that I, for better or for worse, thought was ineffective. I would then redirect us on to what I felt was a better path. In true catalog form, here’s the list:

• Understand the Problem vs. Jump to the Solution - only a couple of minutes into our discussion solutions were being flung about like drunken darts. This situation almost always leads to suboptimal or faulty solutions. As a facilitator, try to ensure that the problem has been clearly stated. If at all possible, write it down on a whiteboard. Make sure everyone agrees that the problem as stated is the problem the group is there to solve. Sure enough, after performing this exercise, we all had a very different and clear understanding of the problem than that with which we walked in the door.

• Assume the Worst vs. Assume the Best - occasionally the exact details of a requirement are unclear, and not assuming something will totally derail the design discussion. You have a couple of choices. The first is to halt the discussion and get the details cleared up. This is clearly the best solution, as you’ll no longer have to assume anything. However, it can be the case that the person who can clear things up isn’t available. Or in some cases, the question you’ll be asking will require another meeting at another level of the organization. If you find yourself in that spot, and you can’t wait (we couldn’t!), then the best approach is to work from the worst possible case scenario. You’ll then be in the best position to handle whatever answer comes your way. However, our tendency is often to assume the best (“That will never happen!”). Fight that tendency. However, whatever you choose, follow up at your earliest opportunity.

• Basing Decisions on the Current Situation vs. Basing Decisions on History - many times the group wanted to veer off into safer territory. In some cases, a possible solution departed significantly from the current design. While this is a valid concern (we do want consistency of design across the system where possible), it is certainly not a trump card. Occasionally the situation at hand will merit a significant departure from the current design. Another way history can rear its ugly head is the assertion that we’ve always solved similar problems like ‘x,’ so we should do so with this problem as well. Again, note the word “similar.” All problems are somewhat different and have their own eccentricities. So, rather than working from history, I pushed us back to a clean slate with the statement “Let’s stop thinking about the past and start from scratch. We may very well come up with the same solution you guys are proposing, but I’d rather do so through our own objective analysis and not instinct.” Guess what. We came up with a different solution that we all felt better about.

• Shooting for the “Best” Solution vs. the “Easiest” Solution - now sometimes we can’t afford the best solution. I grant that. However, I’m trying to fight the tendency to immediately jump to the “easiest thing that could possibly work.” Often this pops up in the first P vs. AP - if we don’t clearly understand the problem, sometimes an easy solution jumps out that doesn’t deal with the underlying details we’ve yet to uncover. Also, sometimes the best solution is quite simple and elegant. It doesn’t necessarily have to be harder and more complex than the easiest solution. In fact, sometimes the “easiest” solution leads to the most accidental complexity in the long-run. So, shoot for the best solution you can come up with and only then, optimize for cost.

• Present Possible Solutions Objectively vs. My Solution is the Best! - one would hope that we all start here, but we don’t. We tend to like our own solutions to problems and want them to “win.” Our ego can get in the way of even hearing an alternate solution presented by another team member. I point you to my colleague Ted Neward’s post for more on “egoless programming.” So, as a facilitator, you’ve got to make sure that all solutions are presented objectively. I often had to say things like “OK, let’s assume before we ever get started that this is a good solution to the problem and not hack away at it until its fully presented, and we all understand it.” In the end, this insistence led us to choose a solution that none of us (myself included) originally thought we’d pick.

• Validating from Code vs. Validating from Memory - more often than not, questions about the existing design/code/behavior will come up. Rather than scratching your head and trying to remember what you wrote six months ago, pull up the code and find out. I can’t tell you the number of meetings I’ve attended where baseless assertions were made about existing code, only to require another meeting the next day to revisit the whole discussion once those assertions were proven wrong. Again, as a facilitator, I directed us to solve every problem for which all of the facts were available. We inserted placeholders in our solution where questions remained. Guess what we’re doing now? Well, I’m blogging about the meeting, but the rest of us are validating from code. Tomorrow will fill in the blanks!

I completed an interest survey for a potential Selenium-focused conference several weeks ago, and I’m excited to let you know that the “powers that be” have decided that the conference is going to happen! I have already submitted my “Executable Specifications: Automating Your Requirements Document with Geb and Spock” talk as a potential session. Whether it makes the conference program or not, I plan on attending the event. Here are the details:

Join members of the growing Selenium community for 3 jam-packed days of talks, workshops, lightning talks, and hack sessions. Hear speakers from around the world talk about the present and future of automated testing, share ideas with fellow Selenium developers, including Core Committers, and take part in shaping the future success of the Selenium project.

When: April 4-6, 2011 Where: Marines’ Memorial Club & Hotel, 609 Sutter St, San Francisco, CA 94102 USA Register now to be a speaker or sponsor. More details: http://www.seleniumconf.com/

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

            ![Featured image](http://s0.wp.com/i/annual-recap/abstract-stats-1.png)

A helper monkey made this abstract painting, inspired by your stats.

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 6,600 times in 2010. That’s about 16 full 747s.

In 2010, there were 15 new posts, growing the total archive of this blog to 115 posts. There were 24 pictures uploaded, taking up a total of 979kb. That’s about 2 pictures per month.

The busiest day of the year was June 4th with 139 views. The most popular post that day was Don’t build software that’s TOO smart!.

Where did they come from?

The top referring sites in 2010 were agile.dzone.com, java.dzone.com, twitter.com, Google Reader, and javablogs.com.

Some visitors came searching, mostly for matt stine, groovy http post, groovy post, groovy url post, and groovy url encode.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

                [Don't build software that's TOO smart!](http://mattstine.com/2010/06/03/dont-build-software-thats-too-smart/) June 2010  

1 comment

2

                [Groovy: Post to a URL](http://mattstine.com/2009/04/25/groovy-post-to-a-url/) April 2009  

4 comments

3

                [Resume](http://mattstine.com/resume/) March 2009                                           

4

                [Deploying Grails with Groovy](http://mattstine.com/2009/03/29/deploying-grails-with-groovy/) March 2009                                            

5

                [LOTY Time Again: Scala or Clojure?!?!](http://mattstine.com/2009/04/02/loty-time-again-scala-or-clojure/) April 2009  

17 comments

Today DZone released my first Refcard: ”Selenium 2.0: Using the WebDriver API to Create Robust User Acceptance Tests.” I have been interested in writing a Refcard for a long time but have never pulled the trigger. For whatever reason, I decided to jump on the bandwagon last month. Writing this card was quite a challenge, as it’s difficult to boil down a big topic into only six pages while keeping it useful. Thus far the feedback from the community has been largely positive.

If you’re looking for your next automated testing tool for browser-based user acceptance tests, download the card and let me know what you think!