I’m excited to announce that I am working up two brand new talks for this Fall to go along side my regular fare. Both of these talks are already scheduled for shows in Boston, MA and Seattle, WA.

The first talk is entitled “The Seven Wastes of Software Development.” We’ll begin by examining one of the key tenets of Lean Software Development, that of eliminating waste. We’ll then walk through the seven wastes identified by Mary and Tom Poppendieck in their books:

• Partially Done Work

• Extra Processes

• Extra Features

• Task Switching

• Waiting

• Motion

• Defects

We’ll examine each of these wastes and look at some of their common manifestations, both in our coding practices and in our development methodologies. We’ll also examine strategies for eliminating each of these wastes from our development efforts.

The second talk is entitled “Yes You Kanban!” Kanban is sweeping through the agile software development space. Is it hype? Or is it a useful tool to add to our belt? In this session, we’ll walk through the following topics and I’ll let you be the judge:

• What is Kanban?

• What is Kanban NOT?

• Comparison to SCRUM

• Roots of Kanban

• David Anderson’s five essential elements/principles of Kanban (Visualize workflow, Limit work-in-progress, Measure & manage flow, Make process policies explicit, Use models to recognize improvement opportunities)

• Examples of Kanban systems

I hope to see some of you in these talks this Fall and I look forward to our discussions!

Hi everyone! I’m currently in the process of developing new talks for my Fall 2010 NFJS tour dates. While I don’t know yet where I’ll be speaking, I can tell you that I’ve registered availability for the following shows:

• Boston, MA

• Seattle, WA

• Atlanta, GA

• Minneapolis, MN

• Chicago, IL

• Denver, CO

So, if you’re in one of those cities and you’re thinking about attending NFJS when it comes your way (see here for the schedule), I’d like to know what you want to hear about assuming I come your way.

To narrow down the potentials a bit, here are my personal areas of focus:

• Agility/Lean/Kanban

• Native Mobile and Web Mobile Software Development (iPhone/iPad/Android)

• Web Development in General (HTML5/CSS3/JavaScript)

• Modularity and OSGi

If there are any topics from these four areas that you’d like to hear more about, please speak up in the comments section. And even if you’re not in one of these cities, most of any talks I develop for the Fall will likely show up on the 2011 tour as well, so please speak up anyway!

Thanks in advance for your feedback!

I had an extremely successful meeting with one of our clients yesterday. We were discussing how we wanted to go about migrating her laboratory from its current system (one that we built several years ago) to our new lab management platform. At some point during the discussion I made the statement, “We tried to make the previous system too smart! We’re not repeating that mistake this time.” Of course, she was in complete agreement with that principle. I’ve had similar interactions with our other clients that are making migrations (rather than encountering our system for the first time on this new version), and although I’ve never explicitly stated the principle that way, similar sentiments have abounded.

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 recently stumbled across the NOSQL Summer website via my friend Alex Miller’s blog. The idea is to setup a summer reading club focused around databases and distributed systems. Groups will gather “worldwide” to discuss various papers and the hopefully submit the substance of their discussions back to the NOSQL Summer website in the form of annotated papers.

This sounded like a great idea to me, so I decided that we’d co-locate a NOSQL Summer discussion with our monthly Memphis JUG meetings. You can find the details of our NOSQL meetings at http://nosqlsummer.org/city/memphis. We’ll start at 5:30 and run until 6:15-6:30. If you’re interested in these discussions, come on out to Southwest TN Community College on June 24th (even if you’re not a Java type!).

Our first paper will be The End of an Architectural Era (It’s Time for a Complete Rewrite). Please read it before the meeting and come prepared to mindshare.

If there’s enough interest in these discussions, we could start having a lunch time discussion at a centrally located restaurant halfway between each JUG meeting. We can discuss this at our first meeting in June. I hope to see you there!

I recently started reading the beta copy of Bruce Tate’s Seven Languages in Seven Weeks from the Pragmatic Bookshelf. While I’m certainly NOT on pace to actually complete the book in seven weeks, I have been steadily plodding along. Reading this book takes me back to my days as an undergraduate computer science student at the University of Mississippi. As with most CS programs, we were all required to take a “Survey of Programming Languages” course toward the end of the curriculum. Tate’s book is very similiar to walking through this course, except:

1. Tate’s text and suggested exercises are intensely practical, targeted at actually getting something useful done in the language.

2. The language selection is entirely relevant to today’s practitioner. Chances are good that you’ll use a language from this set in your day job sometime in the next decade. Ignoring that, chances are good that you’ll use some language that is a “close cousin” of a language from this set.

3. Your thinking about programming in general will be challenged by each chapter. This is not a leisurely read. You cannot “coast” through this course.

At present I’m slowly working through the chapter devoted to Io. Io is a prototype-based language, close-cousins with Lua (of recent iPhone game development controversy) and JavaScript (can’t think of a practical use for this guy…umm…oh wait!). I’ve very much enjoyed Bruce’s treatment of the language, with his descriptions of the feature being as “visual” as words can effectively be - who else could liken languages to popular movie characters and get away with it? Before working through Io, Bruce and I tackled Ruby together. Ruby is an old and unfortunately neglected friend of mine. We’ve had our fun together doing a couple of small Rails applications, JUG talks and a (so far) unsuccessful trek into the world of OSGi, but unfortunately we haven’t hit the big time in my day job. Working through this chapter really served to reignite my enthusiasm for the language, especially as it relates to the rich ecosystem of testing tools available in the Ruby and Rails communities.

In short, only two chapters in I’d thoroughly recommend that you purchase this book. Like Beyond Java before it, Bruce has again challenged us to step outside of our comfort zone. If nothing else, you’ve got seven kickstarts into learning your “Language of the Year.”