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!

What is too smart software? In our case, it was a system that attempted to encapsulate every single rule of “business” process that occurred within a given laboratory. Many times statements were flung around like “will it ALWAYS happen this way,” “what should we do if this happens?” etc., etc., etc. We tried to cover every single possibility, and we did an excellent job of preventing users from ever breaking their own rules. What we didn’t realize (and we’re not unique – this problem is RAMPANT) is that the rules CHANGE. Rules come, rules go. Sometimes the rule remains, but there are a few exceptional cases that must be dealt with. Our system simply couldn’t deal with a world that worked this way – and thus, our system was completely unfit for the real world.

We set out with a different mission this time. If there’s one overriding characteristic of SRM (Shared Resource Management) 2.0, it’s the explicit assumption that the world will change continually. We don’t attempt to tell you how you must use this system. We capture your data, we invoice for your services, we run your reports – but YOU, the user gets to decide how you’ll interact with it. If your workflow changes, we change with you. Now the devil is in the details. It’s taken roughly 20-30 man years worth of effort to build a system like this, and it hasn’t been easy. But in the end, we’re finding that those years were much better spent ENABLING our users rather than PREVENTING our users from getting things done.

I’m not sure that I’ve gotten my point across in this brief diatribe, so I’ll attempt to sum it up here. If you’re developing a system, figure out the 2 or 3 things that will make your users’ lives AWESOME, and do those 2 or 3 things extremely well. Don’t do the rest AT ALL. Don’t build a system that attempts to be smarter than the knowledge expert using it – it’s a means to your user’s end, not an end in itself.

I think that this advice is very applicable to us as software developers today. While our industry is still young enough that a great many of our “founding fathers” are still around, it is surprising to see how often their work and contributions go unnoticed by the vast majority of us. At the January Memphis/Mid-South Java User Group meeting, our program focused on books that all of us as developers should read. Four of us gave our takes on the topic. Joel Neely, one of a few people that I learn from every time I get near them, pulled yet another rabbit out of his hat by focusing on several books, all of which had been published before the majority of us were out of diapers! One book struck me in particular: A Discipline of Programming by Edsgar W. Dijkstra. In it EWD “presents a formal approach to developing (non-deterministic!) algorithms, using what we would now call a DSL for algorithm design. Incidentally, that book was published in 1976.” (Thanks Joel for the excellent summary). I’d like to pull out just a couple of quotes from that book:

A most important, but also a most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language, this influence is – whether we like it or not – an influence on our thinking habits.

Just out of curiosity, does this sound anything at all to you like the frequent admonitions to learn a “language of the year (LOTY)?” Of course that isn’t the context of EWD’s quote, but the underlying principle remains the same. Almost universally accompanying that admonition is a statement along the lines of “even if you never use it in your day job, it will affect THE WAY YOU THINK about programming during your day job.”

…a carefully chosen separation of concerns is essential for the design of in all respects, high quality programs…

Does “loosely coupled, highly cohesive, modular architecture” come to mind?

…the fact that programming languages could be used as a vehicle for instructing existing automatic computers, has for a long time been regarded as their most important property…we shall try to redress the balance, and we shall do so by regarding the fact that our algorithms could actually be carried out be a computer as a lucky accidental circumstance that need not occupy a central position in our considerations…I view a programming language primarily as a vehicle for the description of (potentially highly sophisticated) abstract mechanisms.

I hear so much of what is bandied about today as “new” embodied in this quote. The calls to liberate programming from its “C” roots by banishing primitives, because hey, primitives are only their to keep “Java from being too slow!” The calls to favor “essence over ceremony” in language design by eliminating boilerplate code in favor of sensible defaults that clear away the noise from the algorithmic intent that we’re trying to communicate. The constant reminders that it’s more important for our code to be readable to humans, not to computers, because that’s what compilers are for.

What’s the point? The point is that most, if not all, of the ideas that are “new” today are simply restatements of past ideas in a different context. A wise man, one much wiser than I, once said “…there is nothing new under the sun” (Ecclesiastes 1:9). Edsgar W. Dijkstra passed from this earth in 2002, but his ideas live on, and they are very much applicable to software developers today. There are may others like him: Donald Knuth, John McCarthy, Alan Turing, David Gries – some dead, some alive, but all giants upon whose shoulders we stand. We would do well to consider their words.

1. Learn Groovy and Grails

   Andy and Dave suggest learning a new language every year, so this seemed like a good goal for me. I can’t say that I’ve truly learned Groovy and Grails in depth, but I did learn them enough to do a presentation on them (as well as Ruby, JRuby, and Rails) at our Java User Group meeting in October, so I’ve effectively touched on two languages and two frameworks for those languages. I’ve since gotten interested in Scala as well. At any rate, I’d like to go deeper w/ Groovy and Grails as I have time, which is scarce!

2. Release HallKeeper v1.0 as part of #1

   This project seems destined to fail. I haven’t worked on it in any meaningful way since the summer. I’ve thought about it in the past week, and I’d actually like to try doing it in straight Java POJOs with Spring and Hibernate since I’m more well-versed in that area. At any rate, it really is my lack of spare time that keeps this one on the perpetual back burner.

3. Read and LEARN the following books:
   • The Definitive Guide to Grails – Rocher
   • The Pragmatic Programmer – Hunt, Thomas
   • Computer Algorithms: Introduction to Design & Analysis – Baase, Van Gelder
   • Concepts of Programming Languages: Sebesta
   • Groovy in Action – Konig

   I’ve pretty much finished #1, got started on #2, and haven’t really touched the last three. Again, the needs of the moment have necessitated I focus on other areas, particularly other books. Recent projects have pointed me to three additional books I’d really like to cover this year, so I may not get to my original list. Here are the titles:

   • Working Effectively with Legacy Code – Feathers
   • POJOs in Action – Richardson
   • Domain Driven Design – Evans
4. Review two books for the JavaLobby/DZone book review team

   This is one I’ve hit the nail on. I just completed my second book review, which will be published some time in the next few weeks. My first review, Ajax Construction Kit: Building Plug-and-Play Ajax Applications, was published in October 2007. These have been rather time consuming and have kept me from other projects, so I don’t plan to take any more reviews this year.

5. Pass the Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 Exam

   Haven’t touched this one yet. Preparing for this will be one of my foci in the coming weeks.

6. Write one Java/software development blog article per week

   I haven’t done so hot on this one. OK, let’s be really honest. I haven’t come close. However, my recent flurry of entries on The Spring Experience 2007 have gotten me into a bit of a groove. I’m going to try to keep up the momentum and finish this year strong.

7. Attend JavaOne 2008 or similar conference

   I’ve actually traveled twice since my original post. My first trip was to the Northeast Life Sciences Core Directors Meeting last November at Cornell University in Ithaca, NY. The purpose of this trip was to present and generate interest around our open source shared resource management system for core facilities, STJUDE-SRM. The trip was a great success. My second trip really fulfills this goal, as I attended The Spring Experience 2007 in Hollywood, FL. This proved to be one of the best technical conferences I’ve ever attended, and also one of the most fun!

8. Start a Memphis/Mid-South Area Java User Group

   I don’t think this goal could have gone any better than it has. In late July I started a Google Group and a small Google Page Creator website to attempt to drum up interest in a Java User Group for the Memphis, TN and surrounding Mid-South area. On July 23, 2007, along comes Diane Tabulog, a technical recruiter with local company Vaco Technology, who convinces her company to throw its support behind our JUG. All of a sudden we have an offer for a meeting location, food budget, giveaways, etc. Later, Clayton Naeve, our CIO at St. Jude, agreed to let us use our awesome conference room at our division’s new offices at 160 Shadyac Avenue to meet, as Vaco’s facilities were a bit small. On August 15, Carol McDonald, a Java Technology Evangelist from Sun Microsystems, offered to speak at our JUG, and we signed her up for the first meeting. Little by little, all of the necessary pieces started to fall into place, including additional free giveaways from Sun, O’Reilly, Atlassian, and JetBrains. The first meeting was a great success, and since then we’ve had two more successful meetings. Our next meeting is Thursday, January 17, 2008. Find out more at http://www.memphisjug.org.

1. Learn Groovy and Grails

   Andy and Dave suggest learning a new language every year. I had already informally started learning Groovy and Grails after JavaOne 2007. Since I already have a head start on this one, Groovy will be my language for the next year (I’m learning Grails mainly because of my web development background – it will provide me more opportunity to apply my Groovy knowledge). This should be an easy way to get started on the goal of a new language each year since my Java knowledge should transfer easily.

2. Release HallKeeper v1.0 as part of #1

   Several years ago I started an open source project called HallKeeper. HallKeeper is planned to be a web-based management system for university residence halls. Life got in the way of this project so it lay dormant for a few years. I’ve recently revived it as sort of a “lab” in which to learn Groovy and Grails, and hopefully have a little fun along the way.

3. Read and LEARN the following books:
   • The Definitive Guide to Grails – Rocher
   • The Pragmatic Programmer – Hunt, Thomas
   • Computer Algorithms: Introduction to Design & Analysis – Baase, Van Gelder
   • Concepts of Programming Languages: Sebesta
   • Groovy in Action – Konig

   When I say LEARN, I mean I don’t just want to do a cursory read of these. I want to really engage the concepts presented in each and apply them to my day-to-day work. I already have a head start reading the first two books. The third and fourth books are actually textbooks from my undergraduate education. I could really use a refresher on these concepts, and I think I’m a much more serious student now as a professional than I was when I was actually a student.

4. Review two books for the JavaLobby/DZone book review team

   I joined this team several months ago and was actually assigned to review two books – again, life got in the way (if you have any small children, you’ll understand). Things have settled down a bit now and I’ve asked to rejoin. Hopefully I’ll be able to crank out some reviews this time and learn something in the process.

5. Pass the Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 Exam

   I want to do this mainly to give myself an excuse to go back over the fundamentals of Java, as well as learn the new features that 5.0 brought to the table in detail (generics, annotations, etc.). I have still basically been living in a Java 1.4 world as I’d say roughly 85% of my daily work is on an application that is still bound to that JDK. So, passing this is mainly just a reason to study, and it is a nice edition to the resume as well.

6. Write one Java/software development blog article per week

   This would be numero uno! I’ve always stressed about the frequency of my blog writing – I’ve felt compelled to write every single day, and I usually end up writing a one paragraph synopsis of some other guy’s blog entry. Not exactly something that will attract many readers. I’ll still post those on a more frequent basis as they keep the content flowing, but I also want to write at least one in-depth article per week to give people something to look forward to. One way I’ll do this is to blog about the books I’m reading. The Pragmatic Programmer provides challenges and/or exercises at the end of each chapter – great seeds for entries.

7. Attend JavaOne 2008 or similar conference

   This one depends on the boss – hopefully I’ll get to travel again this year. I’d love to go back to JavaOne – I learned a lot, and big geek shows always motivate me to go back and introduce new technology to the group, as well as get more involved in the community. I always feel a surge in my professional development in the 2-3 month period following my attending a conference.

8. Start a Memphis/Mid-South Area Java User Group

   We don’t have a JUG in this area and I really think that we could benefit from one. My company has a large number of Java developers, and I know that several others in the area, including FedEx and Autozone do as well. This would be a great way to get some of the good speakers from the conferences I’ve attended to speak locally, and it may even serve to get us on the map with some of the smaller shows like NFJS. Sun and others really seem to take an interest in supporting JUGS, so I look forward to see what happens. I’ve started a Google Group for the newborn JUG, and I’ll be blogging more in the future about it.

Who has ideas about the best way to go about this? Please comment!