More unique insights from other people's minds

Uncle Bob recently posted his thoughts on test driven development couched in a critical light.  Not critical as in negative (this is TDD and Uncle Bob, after all).  Rather, critical in the sense that he attempts to ask those questions usually posed by TDD skeptics and then proceeds to answer them.   I usually enjoy Uncle Bob's writing, but this one struck me as particularly well done (I really like its perspective).

There's an excellent presentation floating around of a keynote Google's Jeff Dean gave on building and maintaining very large, very distributed systems.  It's pretty good.  If you work with large scale systems, you should read it.  In fact, even if you don't, you should read it (it's likely you eventually will).

Other Peoples Words (a lazy man's perspective)

Some really great tech articles this week that I'm digging on ...

• Closing the Gap Between Apps and Operations (this gap is one of my pet peeves)
• Cucumbered (I can never get enough of this framework - love it)
• Deploying to Production Every Week (and the discipline to be able to pull it off)
• Spring 3.0 RC 1 Overview (a good overview from one of Spring's two Dads)
  
• More Meta-Metrics (I love everything about this blog, but especially the attitude)
  

She's a brickhouse ...

I'm digging the idea of Sitebricks and plan to take it for a test drive this weekend.  Maybe it'll reinvigorate my energy for web frameworks that has been exhausted by plethora of offerings out there, most of which seem pretty darn similar despite all their claims for uniqueness.  Even if I love it, though, it's unlikely I'll see it much in the enterprise (where I tend to spend my daytime hours).  Also, it would have to be pretty amazing - and different - for me to get over my anger a them for developing yet another web framework.  My bookshelves are getting heavy (even my virtual bookshelves have a weight limit, measured more in the strain on my eyes and frontal lobe than mass).

Passive-Agressive Developer Personalities - which one are you?

If you don't follow Ted Zuiba's blog, I recommend you check it out.  I love his sardonic sense of humor.  He can be pretty brutal with this commentary.  But, really, that's what's great about it.  Also, he's got some pretty cogent advice.

As per usual, there's some interesting work afoot on the Agile Web Operations blog.  The latest is a great one on development team motivation.  Or rather, the supposition that development teams don't need motivation (they're already motivated when they come onboard, that's why they accepted the job offer).  We simply need to actively stop de-motivating them.  You might say this is just arguing semantics, but I think the difference in perspective is illuminating on many fronts.  At its heart is the notion of developer as thinking individual who takes an active interesting in learning new things and advancing their capabilities.  Developers who don't treat training as a 'let me just sit back and let the teacher wash this know-how over me' but rather 'this is a chance for me to learn - learning is the active verb here more so than teaching'.  I think you want to weed the passive 'teach-me' types out of the organization in favor of the 'let-me-get-in-there-and-learn' sort.

But that's just me.  If you disagree, perhaps we can start a developer exchange program.

The Spinning Continuous

Martin has posted another interesting musing on Feature Branching. It's particularly enlightening on its coverage of the thorny problems related to this practice with large scale concurrent (and sometimes conflicting) development - the Fear of the Big Merge - and how Continuous Integration can help.

Martin points out that the more recent Distributed Version Control Systems (DVCS) such as Git have largely solved the visibility and understanding of syntactical or textual differences when merging but they can't solve the semantic differences. And they aren't any help when refactorings have renamed, reshaped and morphed classes, methods, etc. The pain of the Big Merge make folks reluctant to do the refactoring necessary to keep the code clean and relatively free of technical debt.

Martin's answer: a variant on the old joke 'Doctor, it hurts when I do this.' 'So don't do that!'
If the Big Merge is painful, don't do the Big Merge. Do a continuous small merge and then when there are semantic uncertainties, communicate with the developer(s) working in that area. Use CI to do the small merges and use your voice and brain to do the communication part.

Simple, perhaps obvious advice - but the best kind usually is and it never hurts to hear it regularly.

It's not innocuous as it might seem but neither as competent as some might fear

Walmart's announcement that they are opening up their e-commerce platform to third party retailers with Walmart Marketplace seems a logical move, just given their ginormous operational capabilities. They'll likely not compete with Amazon in the cloud computing game any time soon (they're too much an old school brick and mortar outfit for that. But Retail as a Service (or the more general Process as a Service as some are calling it) is perhaps a much more lucrative biz and the old boys in Arkansas (or at least the young turks who have the old boys ear) are coming to understand this.

It's kind of scary but should be interesting to watch.

I guess I'm not as nervous as perhaps I should be simply because I'm guessing they have enough folks in the big seats in the executive bathrooms who are clueless when it comes to a business/technology marriage. And, more importantly, another group in the slightly smaller stalls with the slight less puffy TP who have just enough of a clue that they'll stumble around a good while before acquiring solid footing in this brave new world.

'She was a cute little ruin that he pulled out of the rubble. Now they are both living in a soft soap bubble' - Declan McManus, 2002

Another REST versus SOAP post to chew on. I usually steer clear of this well-worn subject like the plague, but for whatever reason started skimming this post and it's kind of useful. I know, I know - REST isn't a protocol, it's an architecture style that's thrown about loosely for a lot of things and you can (in a narrow sense, with enough effort) "do" REST using SOAP (2.0).

Maybe it's the pragmatist in me but I think it comes down to what the consumer needs are. You remember them, right? What do they look like? Do they need the WSDL trappings or any of the WS-* protocols that require SOAP as their base? Are their message exchange patterns consistent with a RESTful style or a more message or RPC based approach?

The answer can be neither - some of the best Web Services out there today are not either REST or SOAP. Many of Google and Yahoo's Web Services are "REST-like" or "REST with extensions". Some of Amazon's Web Services are SOAP, some are quasi RESTful, some are Query style and some RPC-ish.

It's all about what the current consumers want. Make the implementations such that it'll be easy to add additional flavors if you come across new consumers who need something else, but do it then, not now. They're not your consumers yet.

You might be gun-shy because you've made those 'narrow' decisions in the past and then it took so much effort to add additional capabilities like this after the fact. That's not a problem of the interfaces you expose, though - that's a probably with the implementation. Doc, it hurts when I do this. Then don't do that.

You do remember your consumers, right Brett? Oh, I'm sorry - did I break your concentration?

Perhaps if all of the great technology debates were framed within the bounds of Pulp Fiction, the world would be a less complex (if more violent and foul mouthed) place.

Actually, it could never be more violent than it is already (and this would be over-the-top movie stylized mayhem).

And if it's more foul mouthed, what the fuck is wrong with that?