Reflection on Past Essays and the Path Forward

After a few years of paid hosting, I’m moving my blog to Google Blogger. When I first bought hosting I imagined all of the interesting, amazing web applications I could build. Sure, I built a few things here and there, but over time the web evolved and the free tools available have improved greatly.

As a part of the migration I moved all posts and comments, doing my best to keep everything as true to the original post as possible. In the case of comments, I migrated the exact text you left along with your name and web address. Unfortunately this means your gravatar ID verification will be lost and nothing will be connected to Google or Google+ IDs. This really makes it obvious how difficult the whole idea of “identity” can be on the web.  If you see a problem, let me know and I'll fix it.

You might also some notice some hiccups in the RSS feed (including a Twitter blast), and for that I apologize. Though, maybe thanks to these hiccups you will take a few moments to read some past posts. I’ve had a good time re-reading old essays and seeing how much I’ve changed over the past few years. And how much I’ve stayed the same.

With this in mind, and with it being a new year, I thought this would be an excellent time to reflect on the trends and ideas I’ve written about over the past three years. All told that’s about 40 essays worth of content.

  • Agile + Architecture. Over the past two years I’ve really shifted focus almost exclusively to Agile software development, software architecture, and what it takes to do a good job combining the two. It seems like nearly everything I write beats around the bush of these two topics.
  • Too Abstract? In some ways I’ve become less concrete and moved further from the “core” engineering practices. I think some of this is a reflection of the world I live in currently contrasted with the world I lived in when I started this blog. Let’s put it this way, it’s much more difficult to make a business case for hard core engineering practices when many of the teams I’ve worked with over the past four years seem to struggle with establishing a solid foundation.
  • Affordance Driven Process Design. Applying affordances to process was sort of a weird idea at the time I first published about it in 2009. Now I’ve developed a wildly successful workshop with Ari Font that we presented at Agile2012 and Pitt Agile. Our workshop gives folks concrete advice on how to use process affordances. Plus, human behavior and cognitive science seem to be the hot new things in the Agile community these days.
  • Beef with Software Craftsmanship. I had some major beef with the Software Craftsmanship movement for a long time. I thought the whole idea seemed kind of dumb. And don’t get me wrong, parts of it still seem silly to me – the mentoring metaphors seem extremely presumptuous to me. Even Luke Skywalker couldn’t declare himself a Jedi without Yoda first deciding he had passed his trials. Luke was lucky that a 900 year old Yoda was still around to teach him valuable Jedi lessons. Sadly, most of us don’t have a Yoda – they’re extremely rare. The craftsmanship mentoring approach seems like having a bunch of self-proclaimed Jedi running around picking up padawan as they please… and as Obi-Wan taught us it’s not that easy to mentor…. But I digress.  I had major beef with the Software Craftsmanship movement, but now I really get where they’re coming from. I’m a little older. A little more experienced. I’ve seen a little more of the world and become a little wiser. Craftsmanship is really about caring. Caring is essential for awesomeness; even the founders of the CMM recognized this.
  • Labels are Boring: A Common Theme.  Speaking of craftsmanship, I’ve grown extremely tired of labels and how it seems to negatively affect folks’ thinking. When Demarco published his “Software Engineering is Dead” article, I was starting my final semester of a Master in Software Engineering degree. WTF, Demarco, why rock my world like that? Software engineering is an idea who’s time has come and past, but so what? It’s just a label for a way of thinking about the world of software development.  But, while I’ve tried to move on from labels, there is still a lot of power in labeling something.  Engineering. Craftsmanship. Agile. Architecture. None of them are really proper labels for the things they describe. As a result it seems I move between the labeled things, trying to blend them together in ways that folks typically don’t try. Knowing that I’m pulling ideas from a label is powerful – being bound to the label and letting it dictate my future is not.

The Future of this Blog

My original goal was to write, on average, one well-conceived essay each month. Writing 40 essays over three years hits the average, though significantly tapering off over the past year and half as I have is dissatisfying and not in the spirit of what I set out to accomplish. While it is a little disappointing, at the same time I’ve increased my participation in the local and national software development communities, generating original papers and workshops. This is certainly in the spirit of my intent here, though, these contributions have almost no public record here.

There are a couple of things I’m pretty excited about trying to finish and flesh out. Hopefully by making a public declaration of their existence, I will be likely to actually do it.
  • I always intended for there to be a “part three” to my series on “exploring the design space.” This third essay was planned to unify the first two parts by describing a risk-based model for pruning a multi dimensional decision tree. If that sounds a little odd, you can imagine why I haven’t circled back to complete it yet.
  • I am sitting on a ton of original research coming out of Ari Font’s and my workshop on process affordances. I think there are some interesting lessons and feedback waiting to be discovered here.
  • I’d like to do more original research, no matter how “amateurish” and “practitioner-focused” it may be. I miss writing about real software engineering practices. My first published experience report was on using science and experimentation to understand and evolve process. I should be taking my own advice on this one.
  • I should write more code, not just prose. Concepts are good. Seeing more concepts in practice is better.

So, was starting a blog a good idea? I think so. Seeing my thinking evolve over time has been fascinating. And it seems that a few people have learned from my essays – or at least I’ve sparked a few ideas and inspired folks to think from different viewpoints about engineering software. Critical thinking is challenging. Writing thoughts down, satisfying. Publishing them, kind of scary. Reading them years later, fun.


Popular posts from this blog

Dealing with Constraints in Software Architecture Design

If you aren't Agile… Then what are you?

Managing Multiple Ruby Versions with uru on Windows