Archive for the ‘Books’ Category

The early years of computing were a like a Renaissance dance, lots of people who somehow manage to get to dance with each other at least once. A Mind at Play: How Claude Shannon Invented the Information Age gives us yet another place to stand and watch that dance.

Claude Shannon is one of those people who fundamentally changed the way we look at the world. The problem with fundamental change is that we tend to be on one side or the other of it. Today we speak of information theory as though it’s as obvious a concept as making paper. Kind of the same way we obsess over software developers being able to write code to sort numbers or reverse linked lists. At some point, the fundamental reality of the existence of high-quality libraries and data structures will make these queries as relevant as requiring people to explain a tape sort. But I digress.

He was a researcher, tinkerer, teacher, juggler, and for all appearances didn’t seem attached to labels. He had Vannevar Bush looking out for him. As an MIT professor, he had Danny Hillis and Ivan Sutherland, among others, as doctoral students. He worked with Alan Turing during World War II. And the box-switch-thing that turns itself off. That was him.

Reading the book, you get a sense of possibilities explored. So often people either dismiss or defer possibilities. He literally had a basement full of them. If only he’d know Ron Popeil, every home might have a few of them.

I don’t know how well he would fare in the world today. In his time, Bell Labs basically paid to have him around. He had cachet. He also helped focus people’s ideas. He brought this sensibility to MIT with him as a professor. We get so terribly wrapped up in being hyper-specialized, in know the what but not the why. To often we come across the proverbial Gordian knot and turn away. People are either unwilling to try, or believing themselves to be special, simply act as though the problem does not exist. (Treating people poorly and flaunting violations of the law fall into this category.) Few people are willing to question the fundamentals. What do you need? What do you have?

The interesting people are those who solve problems and help other people solve problems, not by merely telling them what the answer is, but by enabling them to see that solutions can come from places that aren’t necessarily rooted in the past ways of doing things.

In our day and age, when we focus on special skills and special languages and special hardware, it would behoove us to remember that there is no best skill or language or hardware. There is only the universe of problems. It is far more valuable to be able to help others see the shape of the solution than to be an individual capable of providing a answer to a well-defined question whose value will in time expire.

Read Full Post »

I just finished reading Blink: The Power of Thinking Without Thinking by Malcolm Gladwell. Perception is a fickle thing. When IBM created a text editor for their mainframe terminals, they ran into a weird problem. They we too fast. Changes were applied to the screen faster than people would perceive them. In order to nudge the brains of their users, they made the screen flash when a change occurred.

Working in an industry where people want high returns on low risk, I find myself at a loss to explain my sense of what is the right or wrong path. On more than one occasion. I have spend days preparing presentations to give decision makers warm fuzzies in dealing with issues which seem perfectly obvious to me. It takes days because there is a long way between perfectly obvious and the breadcrumb laden trail that people seem to need.

Unfortunately, you can’t Google yourself into a state of experience. So the question becomes, you do want to understand or just cover you ass? A paper trail does this quite nicely. At some point, you must make the decision.

If you want to glimpse the process, read the book.


Read Full Post »

I’ve just finished reading Code Warriors: NSA’s Codebreakers and the Secret Intelligence War Against the Soviet Union by Stephen Budiansky. It tells the story of the US National Security Agency (NSA) up through the end of the Cold War.

Given the number of dry histories of the people and agencies who deal with cryptography and spying, this book is reasonably readable. If you’re looking for a less arch, and more human view on how things got to where they are; you’ll like this book.

The takeaway from the book is that the biggest hindrance in the world of security is people. People who are control freaks or don’t believe that rules apply to them, or believe that the “other side” is stupid, or are just too damn lazy to do the simple things that would avoid issues are the problem. You can’t design your way around them. If you try, you’ll only make things worse.

You can’t pretend you have the moral high ground when you’re collecting enough information to make the US National Archives, the Library of Congress, Google and Facebook look redundant. I’m not picking sides, I’m just saying that if you’ve got a hammer and you use the hammer, own up to the fact and don’t go around telling everybody and their brother that they shouldn’t use hammers and that in fact that hammers either don’t exist or are illegal (or would be if they did actually exist, which they don’t).

Along the way, you’ll be introduced to a cast of well-intentioned, clueless, brilliant and ruthless individuals. There are miscommunications, denial of responsibilities, bruised egos, moments of insight and face palm moments.

Please keep in mind Hanlon’s razor.


Read Full Post »

The Chrysanthemum and The Sword is an exploration of what makes the Japanese tick. At least from the standpoint of a early 20th century scholar. Ruth Benedict was one of that era’s foremost anthropologist.

I could go into the interesting discussion of how the American and Japanese cultures are compared and contrasted. Or how she describes the Japanese approach to Buddhism as being free of non-corporeal entanglements. I’ll leave those to the earnest reader.

What made the greatest impression on me was the lengthy and detailed exploration of on (恩) and giri (義理). These can broadly thought of as debt and obligation. In the west, we have a fixation on equivalent exchange. We like to pretend that there is nothing which cannot be fully bought and paid for. The Japanese fully recognize that this is not the case and have build a society around the concepts of overlapping obligations.

One that I have always found difficult to explain is that of shogimu (諸義務) or obligation to one’s teacher/mentor. This is always an asymmetrical relationship. The apprentice has nothing to offer in exchange in comparison to what they are given. In the west, we, as they say, “just take the money and run.” This is especially true in regard to the attitude of Googling for the answers. People have come to believe that they can monetize the collected knowledge of the world without cost to themselves. The problem comes not to this first generation, but to the second and finally fully realized in the third generation of internet users. The problem is that of who supplies the knowledge.

One of the big complaints of the pre-internet era was how big companies hoarded knowledge, making it available only at a premium. Should it not be free to all? Between the small band of developers (relatively speaking) who contributed to open source, the internet and google, we find ourselves in a place where you don’t need a master to monetize. And so rather than having to pay for software as a function of complexity and craftsmanship, we tolerate mediocre software because it’s free (with ads or in exchange for our personal information).

Meanwhile that high quality software we wouldn’t pay for when it was $400 with a year of updates, we will pay for when it’s a $120 annual subscription to a cloud service. Except that now if we stop paying, we lose access.

But back to the thorny question. Do we really believe that the Google-for-code and I-built-it-all-from-other-people’s-stuff crowd are going to give back to the community? What will happen when those who made all these goodies possible and available retire? If we take the C++ community as an example, there are hundreds supporting millions. This doesn’t scale.

Answers? Nope.

Thoughts? Some.

Personally, I’ve got a bucket full of on, so I should get back to it.

Read Full Post »

One of the nice things about taking months or even years to finish reading a book is that it gives me plenty of time to reflect on it. Sure, I could binge read, but the material is far less sticky. The longer I spend with a book, the more connections I can make. “Failure Is Not An Option,” which I just completed a few days ago, is a good example of this.

The book itself is a retelling of history of the manned space program from the point of view of someone intimately familiar with the events. At first blush, it would appear to have nothing to do with the process of software development. The Apple Pencil I’m using at the moment probably has more computing power than anything available at the time. So, what is the connection?

It is absolutely true that when dealing with matters of human life that failure is not an option. When you look at the history of American manned space flight from the outside, the only thing you see is the ultimate expression of this. You see successful execution, even in the case of unforeseen situations. And that’s the key, it’s from the outside. Success was not achieved because perfect people perfectly executed perfect plans using perfect equipment under perfect conditions. Yes, there were times when the execution, equipment or conditions were perfect. Most of the time, success was ensured inspite of less than perfect conditions. For me that’s the story.

During the space program, failure was a mandate. When you exist in a world of constrained resources, the best way to ensure that you will be successful is to see how you respond when the resources that you depend upon are available. But, wouldn’t you always being everything you needed and have it on hand? One would hope so, but let’s say, for the sake of argument, that you didn’t. What then? If something bad happens, how much time do you have to get things back on track before it’s game over? Well, that depends on what happened, when it happened and how important it was.

Okay, sure, fine, but what did they do and what does it have to do with software development?

In the case of the space program, failure was ensured before the mission. Every possible they could conceive of. Teams of people had the sole job of enducing failures during mission simulations. We’re not talking SimCity or Second Life here. These simulations were conducted in physical hardware as identical as possible. The difference is that this user interface was driven not by physical sensors, but computers. Crews were made to experience failure over and over until their responses were second nature. When you think about it, this is no different from any physical endeavor. The more you train yourself to respond to situational changes, the better your performance becomes.

As of late, I believe that many of the problems with software and hardware have been coming about because of a focus merely on the “happy path.” The idea that we should worry first about making it work and then later about failure conditions. Unfortunately, once management sees something that “works,” they  are unlikely to allocate time to break things. The situation has been made worse by the attitude that software will be tested in beta.

As a result, not only is inferior quality software being produced, but the software is being used in environments which expose their data to exfiltration. We see this is malware infecting point-of-sale systems. We see it in OpenSSL and other open source code. Software being widely adopted under the assumption that someone else must be testing it. Entire generations argue for speed over safety.

So, why has this attitude taken hold? Is it harder to design for failure first? Not really. In fact, it makes unit testing easier as it builds in the failure paths before the actual implementation. But doesn’t this make the code slower? Not implicitly. Between the use of modern tool chains and profile guided optimization, the cost of fail first, fail fast is minimal. Why don’t we do privilege segregation? For the same reason we don’t apply principles of  MVC, MVVM or VIPER. People sit in front of a screen and type. They use the excuse of doing “agile” development on short cycles for not properly planning. Now, I have nothing against short cycles, but to be used properly, you have to accept that not every problem can be evaluated, solved, implemented and tested in 2 or 3 weeks. Some things are hard. Some things can only be accomplished by specific individuals. Some tasks have dependencies on outside resources. Software isn’t building IKEA furniture. There are high level of indeterminacy that can and do crop up.

Neither can we pretend that the software we create lives in isolation or that security is the responsibility of the user. Holding onto data simply because it would make the developer’s job easier during development is not enough of a reason. Not using OS provided encrypted data storage because it makes it harder to debug is simply lame. Transmitting data in the clear or without access control just invites both data exfiltration and command-and-control injection.

Here’s the thing. If you want to succeed, you must fail. You must fail first and you must fail fast. Failure helps to characterize the system. It helps in the creation of documentation. It helps validate the design. Failure makes gives you a better understanding of the problem space. In short, failure is not an option; it is a requirement.

Read Full Post »


My fiction to non-fiction ratio is in general fairly low.

That being said, I do like the occasional Dan Brown novel.

Inferno is one of those books that begs to be made into a movie. It doesn’t so much have chapters as it does scenes. It’s not Dickens, but Dickens isn’t what I would consider as my go-to author when I’m traveling.

As one might expect, there are plentiful historic references, plot twists and general dashings about.

Robert Landgon has become the Henry Jones, Jr. of modern fiction.

In general I find it to be a guilty pleasure.

Read Full Post »

I wasn’t sure what to expect from Giles Kemp and Edward Claflin’s book “Dale Carnegie: The Man Who Influenced Millions.”
Having been a member of several speech clubs in the past, as well as having made a lifetime worth of presentations, I really didn’t think there was much to be learned from Carnegie’s course.

I came across a review of Carnegie’s book that mentioned that Carnegie left out a chapter on dealing this toxic personalities. This is the book referred to.

To some extent, I find Carnegie’s life to be ironic. To the public, he’s perceived as being the the perfect speaker and someone at ease in any situation. In reality, he was uncomfortable outside of his “school’s” environment. He created a mechanism that allows people to be more self-assured and better at dealing with others. But, being able to teach others does not imply mastery of the techniques being taught.

In my reading of impactful individuals from the last 300 years, I am saddened that there is very little possibility for someone to replicate their path in today’s world. Carnegie never completed junior college ant yet was able to achieve great success teaching even the captains of industry.

Unlike the traditional biography, vignettes are presented from contemporary (1989) Carnegie classes.

The book is well worth the read.

Read Full Post »

Older Posts »

%d bloggers like this: