Category: Books

Book: Crooked Little Vein

The writing in this book is good, and I’m always a sucker for noir.

But it gets tiresome after awhile, all the balls-out crazy stuff and topics.

There’s a lot to study about fiction dynamics here though fueled by the picador plotting: lots of interesting characters, lots of mini-plots; paring characters; the weak male/strong female trope; unlimited budget; snarky, but weary direct address tone to the reader; maybe world building, but just as the back-story for the various characters you meet (the serial killer on the airplane, the Roanokes, but the Bob character is ignored/anemic in this respect); social commentary as asides (from Trix, often); sex for titilation.

Obviously I liked it enough to quickly read it.

We’re getting exactly the government IT we asked for

If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.

Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.

You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”

A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”

Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)

But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.

Works as Designed

Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:

The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).

And then summarized as:

…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.

Which is to say: you wanted this, and so I am giving it to you.

The Agile Bureaucracy

The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:

While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.

These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.

Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.

Learning bureaucracies

The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:

Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.

So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.

Programming the human mind to operate in the market, or just buy shit

More from The Attention Merchants

First, on advertising as a decision making lubricant:

Information cannot be acted upon without attention and thus attention capture and information are essential to a functioning market economy, or indeed any competitive process, like an election (unknown candidates do not win). So as a technology for gaining access to the human mind, advertising can therefore serve a vital function, making markets, elections, and everything that depends on informed choice operate better, by telling us what we need to know about our choices, ideally in an objective fashion.

And then an example of that principal in place to sell ads at CBS, early on:

“Here you have the advertiser’s ideal—the family group in its moments of relaxation [listening to the radio] awaiting your message,” said CBS. “Nothing equal to this has ever been dreamed of by the advertising man.” It is, as we shall see, one thing to sell access to the minds, quite another to predict reliably the audience’s frame of mind; and by dictating the moment of infiltration, radio claimed to do just that. At the time and place of CBS’s choosing, the audience would be “at leisure and their minds receptive.”

Overall, The Attention Merchants is good stuff so far.

“we overestimate our own capacity for truly independent thought”

From The Attention Merchants:

Any communication, Lippmann came to see, is potentially propagandistic, in the sense of propagating a view. For it presents one set of facts, or one perspective, fostering or weakening some “stereotype” held by the mind. It is fair to say, then, that any and all information that one consumes—pays attention to—will have some influence, even if just forcing a reaction. That idea, in turn, has a very radical implication, for it suggests that sometimes we overestimate our own capacity for truly independent thought. In most areas of life, we necessarily rely on others for the presentation of facts and ultimately choose between manufactured alternatives, whether it is our evaluation of a product or a political proposition. And if that is true, in the battle for our attention, there is a particular importance in who gets there first or most often. The only communications truly without influence are those that one learns to ignore or never hears at all; this is why Jacques Ellul argued that it is only the disconnected—rural dwellers or the urban poor—who are truly immune to propaganda, while intellectuals, who read everything, insist on having opinions, and think themselves immune to propaganda are, in fact, easy to manipulate.

I’m hoping to bundle this book up into my next book review for The New Stack.

Book Review: Automation & tech ethics, book review

These two books go well together because the first describes how automation is lowering the need for labor, leading, likely, to less jobs, while the second provides a compendium of examples of such software-driven labor change.
Vinnie’s book has the optimism of a technologist, while Avent’s is much more fraught. Both accurately describe how IT is optimizing and replacing “analog” labor and businesses, leaving the core problem of devaluing human labor, perhaps to the point of eliminating millions of jobs, permanently. Vinnie’s optimism is the usual believe that we can figure it out, mostly by being more humane in our politics and safety nets, but also in the belief that new problems and jobs will come about. Avent, on the other hand, offers little in the way of solace.
As the review in his magazine, The Economist, put it: “I found the virtuosity with which Mr Avent knocked down possible solutions disquieting.” Aside from actually reading the book, the lecture Avent gave at LSE is good stuff too.
Check out the full review.

Book Review: two DevOps books

Check out my review of the DevOps Handbook and Start and Scaling DevOps in the Enterprise over on The New Stack.

Unsurprisingly, I liked both of them, esp. the second:

What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.

Book Review: Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations

The premise of this book, for most anyone, is painfully boring: planning out and project managing the installation of COTS software. This is mostly lumbering, on-premises ERP applications: those huge, multi-year installs of software that run the back office and systems of record for organizations. While this market is huge, touches almost every company, and has software that is directly or indirectly touched by almost everyone each day (anytime you buy something or interact with a company)…it’s no iPhone.

If you’re in the business of selling enterprise software and services, however, Beaubouef’s book is a rare look inside the buyer’s mind and their resulting work-streams when they’re dealing with big ol’ enterprise IT. As a software marketer, I read it for exactly that. I was hoping to find some ROI models (a scourge of my research). It doesn’t really cover that at all, which is fine.

There’s a core cycle of ideas and advice flitting in and bout of the book that I like:

  1. COTS software will do, you know, 80% of what you like. The rest is customizing it through configuration, your own code layered on-top, or getting the vendor to add in new features.
  2. The more you customize the software, the harder it will be to change. But, the less you customize it, the less it creates differentiation for your business processes.
  3. Most of the problems and challenges you’ll encounter, though, will be human based.
  4. Much of these human problems are about managing the requirements process to make sure the software is matching the needs of the business.
  5. Process-wise, to do this we like to take on a waterfall approach (try to specify everything up front, implement it all, then verify if it works). This results in a lot or risk of waiting for that final verification to see if it works and you were right about matching the COTS implementation to business needs.
  6. Instead, and iterative approach that focuses on learning and honing the COTS/business match-up seems like a good idea.
  7. Role-wise, getting someone(s) who have a tops-down view of the business process and enough technical understanding to map that to the COTS project is a really good idea, though hard to put in place.

While the book focuses on on-premises software, the overall thinking could easily apply to any implementation of a large IT-driven, vendor provided system: SaaS would work, and to an extent the kind of infrastructure software we sell at Pivotal. As the points above go over, the core thrust of the book is about managing how you make sure your IT is actually helping the business, not bogging down in its self.

If you’re pretty vague on what you should do in these large IT initiatives, you could do a lot worse than read this book.

Check out the book: *Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations *

Book Review: Zero History

Rounding out the “Bigend Trilogy,” Zero History is up to the standards you’d expect from William Gibson’s “in the present” stories. Reading through it, you can feel the mastery of his own style of that Gibson has: soulless, unsentimental, and over saturated with a sort of frenetic calm. As with most science fiction, the plot is more of a fixture, and characters are almost equally part of the set. The more pleasurable part is the atmosphere created, here, from places like a “private hotel” with ornate-weird interior decoration, fashion-fetishizing, London motorcycle couriers, and even a brief stint in blown-out rural America.

As with the previous books in the series – Pattern Recognition and Spook Country – the plot itself is the mystery of the book: trying to figure out why all these characters are being compelled to hunt down the secret “Gabriel’s Hounds” clothing maker. There’s some frenetic, tacked on action at the end (as usual) that makes for the major look into characters – what will they do when forced to make a “difficult choice” – but all of that is just background imagery for the more comfortable string of scenes Gibson paints in the rapid chapters.