Sunday, March 1, 2015

Embracing Change

I recently listened to a recording of a webinar put on through the ACM titled "Agile Methods: Agile Methods: The Good, the Hype and the Ugly" where Bertrand Meyer (the Eiffel/Design by Contract guy) gave his interpretation of the agile software movement, and how we may tweak agile thinking. 

A point in particular caught my attention.  He talked about a rephrasing of some of the agile principles as stated in the manifesto, and in particular he talked about rather than "embracing" change, one should "accept" change.  While this might seem like splitting hairs, I think it an important distinction, and one I completely disagree with.  I'd like to elaborate why I feel the distinction matters.

The rationale behind Meyer's thinking was that nobody is happy when they have to throw away work.  Say you built a fancy front end for a payment system and then after weeks of development the customer says "nope, that's not what I want" and you have to throw it away.  You're obviously not going to be happy about that, but given the customer pays the bills (and as such your salary), you have to just roll with that punch and start over.  As such, Meyer paints this picture of the developer who begrudgingly throws away his/her pristine work, all the while muttering under his/her breath about how the customer can't make up their mind and resenting the indecision.

I agree with this in principle (I don't like to waste my time), but it fundamentally misses the point of not only the agile philosophy, but of modern professional software development.  As a developer, I don't want to build things for the sake of building things, I want to build things that solve problems.  In particular, I want to build things that provide value to a user (ideally a user who will pay for such services, but the monetary unpleasantries I tend to leave to the business folk).

That is, if what I'm building isn't what the customer wants, I don't want to build it.

This is important.  I'm a craftsman, so I very much care about, and put my entire energy into writing the best code I can, building the best systems I can, but I fully recognize that none of the stuff that goes into that "quality" equation matters if you're building the wrong thing.  As much as I love development, it's value is instrumental, not intrinsic.  If the stuff I create never gets used, then it doesn't matter how good it is.

With this in mind, hell yes, I embrace change.  When a customer gives feedback and says "that's not quite what I want" it's music to my ears because it means I'm now that much closer to building the right thing.

So yeah, don't just accept change, embrace it.  Wrap it around you like a warm blanket, secure in the knowledge that because of that change you're now even closer to building something truly amazing that will change people's lives.

Tuesday, February 3, 2015

Book Review: The Software Craftsman

Book: The Software Craftsman


Author(s): Sandro Mancuso
Publisher: Prentice Hall; 1 edition (Dec 14 2014)
Pages/Sections Read: All, cover to cover
Thumbs up/Thumbs down: Thumbs Down
Link(s): Amazon, Author's Twitter

Summary Of Content Read

This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftsmanship North America (SCNA) conference in 2013, and found his talk uplifting, and inspirational. As a result of that, when I saw this book had been released it was an "instant buy" for me.

Ultimately though I was incredibly disappointed by this book.

I wanted to like this book. Rather I wanted to love this book. And honestly, much of what Sandro espouses in this book I agree with and believe. But, this book is poorly written and filled with anecdotal "evidence" to support his claims. This is a shame, as there is much well documented, well-researched evidence to support much of what he argues for. See, the thing is when you make empirical claims (ie - if you do TDD you will reduce bugs and therefore reduce costs, or if you pair with other developers you will create a culture of learning which will improve productivity, or if you hire craftsmen your company will be better off), you need to back that up with empirical evidence, not just "I had this job once where we did this & it worked...".

By in large if you've ever followed the software craftsmanship community, you'll have heard everything that you'll read in this book. TDD is great so it's an encouraged practice, but we don't hold practices in a dogmatic way. Pragmatism is key. You can't be a great developer without being passionate. Commit yourself to lifelong learning. The craftsmanship movement is about raising the bar. On and on and on, it's all the standard tropes you hear in conversations about software craftsmanship. I went into this book expecting to see something new, or some deep insights, instead I got a series of blog posts that felt very much like preaching to the choir.

There's also lots of heavy-handed "preachyness" in this book. Lots of defamatory comments towards managers, agile coaches, and architects (though back-pedalled in the appendix), and lots of "if you don't do this, then you're doing it wrong" type rhetoric, which I found surprising. The craftsmanship community is supposed to be about celebrating diversity and being welcoming of anyone, of any skill level so long as they're willing to better themselves and learn more.

There's also lots of inflammatory/adversarial commentary (ex: "QA teams are an anti-pattern", "are you good enough to work on legacy code?", "tech debt items are an excuse to justify bad code", "software craftsmen are never scared to lose their jobs", "only incompetent people fear losing their jobs", "university degrees don't mean anything", etc) that feels very elitist & arrogant. Lots of straw man commentary, painting conversations with Dilbert-esque pointy-haired bosses in a very biased light.

Lots of sweeping generalizations, and little in the way of new insights. There's a lack of focus or coherent theme to the book. Who is this for? Is it for "apprentice" craftsmen? For people who've heard about this software craftsmanship thing and want to know more? For the Bob Martin's of the world? It's so inconsistent, some of it feels written for an audience who's only vaguely familiar with the craftsmanship movement, and other parts feel like unless you've been writing code for decades you'll have trouble relating.

I'm being overly harsh, there are nuggets of really good insights in this book and he certainly knows the craftsmanship movement. The thing is though there's nothing you won't get from simply reading the blogs or books of some of the people in the craftsmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book.