• Yes You Kanban!
• The Guerilla’s Workflow
• Feedback is the Key!
• Going Guerilla: Where to Start

In the near future you can look forward to a few more episodes of “The Agile Guerilla” series, as well as a brand new series I’ll be starting entitled “The Seven Wastes of Software Development.”

Got any topics you want to hear more about? Post up in the comments and I’ll see about covering them at Agile Zone in the coming weeks!

I recently accepted the role of Agile Zone Leader at DZone.com. For the past few weeks I’ve been publishing a couple of articles a week on various agile development topics. I’m very happy to get the extra exposure and I hope that folks are getting some value out of my posts. On the downside, I have virtually zero time to write anything here, but on the upside I’m definitely writing more regularly. Nothing like positive pressure to deliver!

Here are some links to my recent articles:

• You Are Your Software’s Immune System!
• Interview: Alan Shalloway on Lean Agile Software Development, Part One
• Interview: Alan Shalloway on Lean Agile Software Development, Part Two
• Show (Don’t Tell), Persuade (Don’t Preach)
• But the ScrumMaster said I had to!
• The Agile Guerilla
• Use Stories to Deliver Business Value

Enjoy!

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!

• 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!

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.

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!

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.”

Yes, one of the next frontiers is to make OSGi easier to use for the web app developers. The solid foundation is there, so stop whining and help us create the tools, books, and tutorials that will make OSGi palatable in those markets.

There’s nothing like a call to action to get me stirred up. It’s no secret that I think OSGi is an excellent tool for tackling the complexity of enterprise applications (see my talks on the NFJS tour this year: http://www.nofluffjuststuff.com/conference/speaker/matt_stine). However, I will readily admit that the learning curve for tackling any non-trivial application in OSGi is rather steep. My bar for non-trivial is quite low – try learning OSGi while simultaneously attempting to get a mainstream framework like Hibernate working properly.

I think that what we need is a tool that will enable a developer new to OSGi to get an OSGi-enabled web application up and running fairly readily. In fact, I think it would be good to absolutely minimize the amount of OSGi know-how required to get a basic web application into production, while at the same time leaving all of OSGi available just under the covers so that it can be easily accessed when I know what I need and how to use it. So here’s my proposal:

1) Follow in the footsteps of AppFuse, Grails, Rails, Roo, etc. and put together a web application toolkit that will allow one to instantly spin-up a deployable OSGI-enabled web application.
2) Since we’re talking about catering to mainstream here, Java the language ought to be the primary language used for development. With that said, we should not put up any barriers to using other languages available on the JVM.
3) Bootstrap a DB-agnostic persistence layer leveraging JPA and make it easily accessible across the application bundles.
4) Bootstrap a dependency injection framework for OSGi services based on the Blueprint standard.
5) Bootstrap a security layer and provide a basic user/role security module with provided login, logout, etc. facilities.
6) Pick a set of modern Java web application frameworks (e.g. Spring MVC, Struts 2, etc.) and make them easily pluggable.
7) Wrap a nice build system around all of this that leverages a modern build tool (e.g. Gradle or Maven 3), the best of the PAX Tools features (especially Pax Construct, Exam, and Runner), and good facilities for automated testing.

So, who’s with me? I’m open to any suggestions/comments/rants, etc.

This talk covers the various things I’ve learned about leading a Java User Group over the past few years. I would say that these are definitely applicable to leading any type of user group, so even if you aren’t a Java person, you might find some meat here. Enjoy!

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.