ntschutta.com

Freedom (TM) is Daniel Suarez’s followup to one of my favorite books of 2009 – Daemon. Required reading for last year’s Hackers B and B, Daemon is a geek friendly book that includes a main character using a perfectly realistic SQL attack to hack into a computer (there’s no “this is UNIX” moment from Jurassic Park here.) Suarez is to geek what Tom Clancy is to military: dead on details abound. I tore through Daemon and I hotly awaited the conclusion of his epic tale. I was not disappointed.

The Daemon is the creation of an ultra rich (mad?) genius game designer Matthew Sobol. When Sobol dies of brain cancer, he unleashes his program on the world where it reeks havoc. Throughout his first book, we’re lead to believe the Daemon is ultimately an evil creation but Freedom(TM) shows us the other side of Sobol’s work. Indeed, we find a new world order emerging as darknet members (people who’ve joined with the Daemon) form new communities committed to sustainability (it’s easy to see where Suarez was influenced by Omnivore’s Dilemma.) Of course the old guard fights back as it sees its power and influence begin to wane…

I don’t want to say too much and ruin anything, but if you’re a geek, a gamer, a programmer or just someone that likes a fast paced action filled book, well then Freedom(TM) is your cup of tea. Some may be put off by the heavy handed political commentary but I wouldn’t let that stop you from giving it a go. I hope this isn’t the last book from Suarez though he’s set the bar awfully high.

The Omnivore’s Dilemma: A Natural History of Four Meals has been on my reading list for quite some time now and over the holidays I finally got around to ordering it – as my first foray into the world of the Kindle. Yes, my dad came through in a big way and allowed me to join the likes of Neal Ford, Stu Halloway and Scott Davis…but back to Pollan’s book. Omnivore’s Dilemma starts with a simple question: where does our food come from? Pollan follows a humble hamburger back to the corn fields of Iowa and ultimately the oil fields of the Middle East showing us how the lack of diversity on the modern farm isn’t doing the farmers, the environment or our midsections any favors. No, it seems modern agriculture is designed to benefit large multinational corporations more than anything else. Shocking. Some will shun meat after reading about its processing but me, well I like a good burger. However, we’ll be picking up some grass fed beef from Thousand Hills shortly…

Part two explores the organic movement from the amazing synergy of a true farm ecosystem consisting of cows, chickens, pigs and grass working together in concert to the, shall we say, less noble minded large scale operations that see a market to tap. We consume a fair amount of organic food but there’s no comparison to what we get all summer long from our local CSA, Foxtail Farm. Thanks to Pollan, I’m more skeptical of the organic label though I still think its ultimately for the better and I’m even more convinced that supporting local growers is an important step – we get better food that’s produced in a more sustainable way.

The last part of Omnivore’s Dilemma looks at hunting and gathering with Pollan crafting an entire meal that he scavenged. He creates an amazing meal that reminds us that food isn’t just about shoveling sustenance into our maws – it’s about connecting with those we love. And it really is stunning what you can find if you know where to look though I won’t be hunting mushrooms anytime soon…

Omnivore’s Dilemma isn’t a new book but it’s still relevant and will definitely change how you approach food. I have a different mindset at the grocery store now and I try to follow Pollan’s advice on diet: “Eat food. Not too much. Mostly plants.” Whether you do all your shopping at Whole Foods or the quickie stop, arm yourself with Pollan’s teaching; you’ll eat better and ultimately you’ll feel better.

Updated to add cover image:

It’s a new year and one of my resolutions is to post more – and to write up my thoughts on the books I read throughout the year. Looking at my Recent Reads page, it’s obvious I’ve let that lag a bit… With that in mind here is the first of what I hope is a relatively steady stream of reviews.

Based on effusive praise from Kathy Sierra, I picked up Cliff “Beyond Bullet Points” Atkinson’s latest book, The Backchannel: How Audiences are Using Twitter and Social Media and Changing Presentations Forever. Atkinson’s book is an exploration of how social media sites like Twitter are changing the landscape of public speaking and while I wasn’t quite as blown away as Kathy was, there certainly are some good points to be found in this quick read. I’ll start with the positive and then finish up with my criticisms.

I can understand why Kathy is so fond of this book – throughout, Atkinson reminds speakers of a vitally important lesson: it’s about your audience stupid. Too many speakers epitomize the “me me me” approach of presenting and that’s a recipe for failure. Though I find the “four tweet” model bit minimal (especially for longer talks), it is a useful exercise that I’ll be incorporating into my talk prep. Again, the notion here is to focus on your audience and really think about the key ideas you’re trying to communicate. I also like thinking about Twitter sized bites – making your talk “Twitter friendly” is valuable advice.

The concept of a presentation home page is rock solid and I think I’ll play with that as well; starting (and fostering) conversation should be the goal of a modern talk. Considering the wealth of ways people can consume information today, live presentations need to offer something compelling to capture an audience. Turning a talk into one leg of a more immersive experience is a worth exploring.

While there certainly were some strong points in The Backchannel, I felt it took too long to get to the key points which is ironic considering Atkinson’s repeated advice to do so in a presentation. I suspect there was an effort to inflate the page count a bit – the first half of the book could be condensed quite a bit. Case in point, I was surprised to see a chapter that was devoted almost entirely to setting up a Twitter account. A number of the graphics did little to add to the material, in many cases, they stated exactly what was already on the page. It also felt like the book was written on Twitter – so many of the sentences and paragraphs seemed to adhere to a 140 character limit.

Atkinson has a great list of ways the backchannel can blow up but not nearly enough advice on just how to recover when faced with those situations in real life. I understand he wants us speakers to *think* about how we’d handle that situation (and that’s great advice) but I was hoping for more of his thoughts here; I wanted more hard won experience from people who’ve lived to tell the tale. The backchannel blowup case studies were useful but again, I wanted more “here’s what they should have done…”

Though a bit light on content, the last couple of chapters make this book worth reading. Atkinson reminds us to focus on our audience and our message and he has some practical advice for dealing with the realities of modern presentations. Just as we can’t turn back the clock to when bullet point laden talks were the norm, we can’t put the Twitter genie back in the bottle. But we can do a better job of engaging and leveraging these tools to make more compelling presentations.

Speaking of interesting videos, Stuart Halloway has been beating the drum pretty hard for Rich Hickey’s talk: Persistent Data Structures and Managed References. I was actually in the audience (along with Glenn Vanderburg) when Rich gave this talk at QCon London and I concur with Stu – this is something you’re going to want to watch. A couple of times. Then watch it again. You’ll thank me (and Stu) later. Oh, and you really should go to QCon. I mean it, it’s a great show with some unique talks.

The video of my DSLs in JavaScript talk [slides - pdf] from QCon is now available on the InfoQ site; many thanks to all those who have written me or tweeted links, I appreciate it! I can’t say enough good things about QCon, it’s a great show with some amazing talks – if you have a chance to go, you really should. But, if getting to London or San Francisco (two of my absolutely favorite cities) isn’t on the radar screen, the next best thing is watching the fantastic videos you’ll find posted regularly on InfoQ. Enjoy!

Where would rather be this December, adjusting to winter or spending a few days in Orlando learning about what’s new and exciting in JavaScript, Ajax, CSS, HTML, design and a host of other topics? If the later appeals to you, book your seat today at The Rich Web Experience! In addition to some great talks by some of the best speakers in the industry, you’ll also have access to the JSF Summit. I think Neal Ford has been listening in on some of my Ajax talks – I call it a seasoning, he calls it a spice, but either way, the user experience is a key to making great applications. See you in Orlando!

Over on JavaWorld, you can see my latest article: Ajax: Tools of the trade. If it’s been a while since you looked at client side development and you still think alerts are the end all be all of web debugging, you might want to give it a read. Here’s the official summary:

Where JavaScript developers were once tool-deprived, today we’re often overwhelmed with the abundance of options. In this article, Foundations of Ajax author Nathaniel T. Schutta reviews development environments, debuggers, testing tools, and utilities that elevate JavaScript to first-class status in the Web development world. If you’re still programming JavaScript in a text editor, this survey of the modern tools landscape should open your eyes — and could make your life much easier.

If you like the article, you might also want to listen to the podcast of Andy Glover and I chatting about Ajax, JavaScript, testing and more. Enjoy!

At QCon, Glenn Vanderburg, Michael Feathers and I (there may have been others, as I recall some ESB was involved…) were talking about Mike’s 10 Papers Every Programmer Should Read post (if you haven’t read it, please do so now, I’ll wait. No really, go on.) A lot of programmers aren’t particularly well read, a fact that Mike laments, and we kicked around some theories as to why that is – here’s mine.

Why don’t we look at our past? I believe it has to do with the natural (10 year or so) cycle of language dominance. People who’ve never programmed in language n-1 look at the syntax in a book from, say the early 90s and scoff; they complain that they don’t know that language thus they can’t read the book. I’ve heard more than a few developers dismiss Design Patterns because the code wasn’t in Java, of course Java is starting to wane – a couple of days ago I was researching a book and noticed it had a bunch of negative reviews because the example code was Java!

Many developers are essentially Blub programmers and they can’t imagine life in any other language. Further, they firmly believe that anything that existed before Blub is the modern day equivalent of the Pony Express, antiquated and useless. To some, all the good ideas are new, and we have nothing to learn by studying our past, I suspect many of these people have never seen the mother of all demos (though maybe we have something new to rival that now.) A typical Blub programmer assumes that any book that doesn’t use Blub isn’t worth his time and thus misses out on a wealth of learning. They almost willfully ignore the past which explains some of the reactions to Mike’s post.

I’ve been doing my best to read my way through 10 papers and this afternoon I came to Kent Beck and Ward Cunningham’s A Laboratory For Teaching
Object-Oriented Thinking. Now, many people assume the whole agile software thing is just a few years old but here we see waaaaaaay back in 1989, a reference to YAGNI and a plug for teamwork:

We stress the importance of creating objects not to meet mythical future needs, but only under the demands of the moment. This ensures that a design contains only as much information as the designer has directly experienced, and avoids premature complexity. Working in teams helps here because a concerned designer can influence team members by suggesting scenarios aimed specifically at suspected weaknesses or omissions.

Great ideas then, a great ideas now. We’re a young industry, one that is further hamstrung by the belief that the language/technology/process du jour is all that plus a bag of chips. We’ve obviously made some huge strides, but in so many ways we’ve barely moved. But for the video quality, Engelbart’s demo could have just as easily been from 1988 or even 1998; sure, we’ve all got a mouse on our desk, but what about that 5 fingered keyboard? Not so much. Heck, every language is just trying to reinvent Lisp, and that’s more than 50 years old! Don’t be afraid of the past, those old guys knew a thing or two. We only hurt ourselves by ignoring the lessons they have to teach us.

As Neal Ford explains, the NFJS Anthology series has been reborn as a monthly magazine and in the current edition, you can read my take on test infecting legacy organizations. I’ve been a proponent of the testing meme for most of my career but I’ve also spent much of that time convincing reluctant coworkers (and managers) that testing was in their best interest – the article takes my talk of the same name and puts it to paper. All NFJS attendees get a complimentary copy of of NFJS, the Magazine, but anyone is free to subscribe. Each month you’ll get an eclectic mix of articles written by NFJS speakers on topics they are passionate about; if you’d like to see a sample article, check out Jared Richardson’s A Case for Continuous Integration [PDF]. Enjoy!

“We’re not a software company” is a common refrain these days; ever since Nicholas Carr’s “IT Doesn’t Matter,” it seems like more and more companies are bending over backwards to prove they don’t do IT. In the process, some consultancies have made a ton of money, often by “replacing” a given company’s IT department with the newly hired agency replete with people from….the company’s former IT staff. More than a few of my friends went to work one day as an employee of company X only to enter the office the next day via a contractor badge. As companies aped one another, we heard more and more about “core competencies” and how smart companies stuck to what they did best.

Implicit in this arrangement is a transfer of risk – and many (on both the business and IT side of the shop) equate vendors with risk free, or at least, if things go south we have a throat to throttle. While it can be empowering to scream at a vendor rep, that doesn’t mean you’ll get your problem solved – or that they’ll even be inclined to try. Vendor priorities mar or may not line up with yours and more often than not, that service contract entitles you to the C squad, not the A players they showed you during the courtship.

Make no bones about it, when you saddle up with a vendor, it’s a commitment, one you best enter into with your eyes open. Just like with your spouse, year two is rarely the same as the first date and having a phone number to call doesn’t mean you’ll get an answer you’ll like – or even an answer at all. Sure, you can open a problem ticket, but when will it be resolved? Don’t hold your breath, unless your CIO calls their CIO at least. Oh, and never assume the vendor’s developers write higher quality code than you do – some of the worst smelling balls of mud were slung by people working for “software companies.”

While we’re on the topic of software companies, don’t automatically think that the vendor is anymore of a “software company” than you are. It may *seem* like they’re in the same camp as Microsoft or Oracle, but take a look at their income statements – does “professionals services” make up a large percentage of the bottom line? Odds are it does, the software is the modern day equivalent of razors; they’ll darn near give it away (OK, if you call 7 figures “give”) so they can line up a nice fat services contract (mmm, smell the subscription fee!) In some cases, your odds of successfully implementing the project rapidly approach zero without a significant investment in contractors at $250 an hour and up. Nice work if you can get it.

Speaking of contractors, before you pull the trigger on that shiny box of vendor joy, take a look around the job boards to see if anyone is looking for developers with that skill set. Better yet, have your HR people look over recent job applicants to see how many boast time with your new love. Staffing models aren’t always at the forefront, but if you can’t hire people to twiddle the vendor bits, take a look around your cube farm and be sure you’ve got something people will want to train up on. Don’t be surprised when your techies aren’t thrilled by the notion of babysitting a piece of packaged software.

Once you’ve committed to a vendor, you live life on their schedule. Occasionally you might be able to nudge things but chances are you’ll be treated like the rest of the huddled masses. In some cases this might be just fine, but in others it can have a significant impact on your business. Found a critical bug? Odds are that won’t be fixed until the next release…sometime next year. You’re also stuck with their priorities and again, while you might have some influence here, more often then not, your pet feature isn’t so important to the decision makers at Vendor Co.

When you bring in a vendor, expect a platform play – and not all platforms are created equally. The excitement in Java land these days isn’t over Java the language, it’s Java the platform that gets the much deserved press for housing the likes of Clojure, JRuby, Scala, Groovy (hint, your developers would love to play with any of the preceding) and a host of others. While the Java platform (and it’s peer from Microsoft) offer a slew of choices, the vendor’s platform is probably designed like the Hotel California; once a company has invested time, effort and money, they will usually continue to throw good money after bad.

I’m not saying you should never purchase a vendor product – far from it. You shouldn’t write your own database server, you own app server, your own OR mapper or your own build framework (OK, maybe as a replacement to Maven, sure I can see that.) But when it comes to core competencies, the things that make your company special, that’s not something you should be too keen on farming out. As my friend Neal Ford is fond of saying, smart companies understand that IT is strategic.

When it is time to purchase some software, perform a true evaluation – and one that’s up to date. Just because the Foobaz team gave the product the thumbs up three years ago doesn’t mean they’d say the same thing today. Heck, that team might not have even considered the same criteria you are. Too often, we either run through a script that is oddly similar to the vendor’s demo or we try out a couple of hello world size examples; you’ve got to spend some quality time with a product to figure out when Dietzler’s law kicks in. Regardless of what you’re evaluating there are certain things you should pay extra special attention to:

• The testing story. If a tool doesn’t have a good *automated* testing story, fail, or as we say in the project room, frog in a bag (FIAB for short).
• Version control. Repeat after me: copying the files to the LAN isn’t version control. Life without source code management just isn’t worth living, if the tool doesn’t fit within something like Subversion or Git, your evaluation is over.
• Can you diff the artifacts? I’m a fan of pictures, but show me the tool that can diff that fancy BPEL visualization. Oh and good luck with those massive XML files.

I’m sure you have other criteria too (Neal has a good list in part three of his SOA series) but these three are absolute deal breakers for me. Again, I’m not saying you should build everything, but when you do choose to purchase, be sure you know what you’re getting into. Can you live with the constraints? Are you comfortable with the tradeoffs? If so, I wish you all the best. But don’t blithely assume vendors aren’t risky.