REVIEW
Review: Algorithms in a Nutshell
Algorithms in a Nutshell
George T. Heineman, Gary Pollice, Stanley Selkow
O’Reilly Media
In the midst of the SDN craze (or haze, depending on your point of view), we often forget that all networks are, in the final analysis, driven by software. Every control plane ever developed or deployed is a software application running on top of a physical device. And every control plane, every queuing mechanism, every forwarding mechanism, and everything we work on in the networking field is based on some sort of algorithm. But what is an algorithm, really? What sorts of algorithms are there, and what are they used for? These are the questions this book specifically takes aim at answering.
The authors begin with a chapter discussing the concepts of algorithms; this chapter contains a really helpful section on the difference between the classes of algorithms available, such as greedy and Chapter 2 focuses on the math of algorithm performance, providing information on the difference between O(1), O(n), O(n log n), and many other expressions describing the feed at which algorithms operate. This is one of the most helpful and clearly explained sections in the book. The third chapter explains the building blocks of algorithms, specifically focusing on the conventions used in the book, and some challenges around measuring the performance and accuracy of any given algorithm.
Chapter 4 considers sorting algorithms, and chapter 5 search. These three kinds of algorithms probably cover 80-90% of all algorithm usage in real code. These three classes of algorithms actually provide the building blocks for many other kinds of algorithms. For instance, Shortest Path First (SPF) requires a sorted heap or list of nodes, edges, and reachable destinations in the network—but we have to sort a list to have a sorted list to use in SPF.
Chapter 6 jumps into material directly applicable to network engineering; here is where Dijkstra’s SPF algorithm is covered. This chapter will be extremely useful to network engineers to read and understand, even though the terminology is often different. Chapters 7, 9, and 11, on path finding in AI, computational geometry, and emerging algorithm categories, are interesting, but not all that useful for the average (or above average) network engineer.
Chapter 8 discusses network flow diagrams, which are a superset of many of the traffic engineering, service chaining, and queuing theory problems engineers face in real networks. Chapter 10 should be familiar to engineers who’ve looked at the m-way trees and treis used in packet switching.
Overall, this is really useful book for network engineers who want to dig deeper into the software roots of how network protocols and switching work. There are a few chapters that don’t directly apply to the common sets of problems network engineering involves, but readers won’t miss a lot skipping those sections if the overall length of the book seems like it’s too much.
The reading difficulty is moderate, and the time to read is pretty long (partially because of the many code examples and the depth of the concepts covered).
Review: The Art of the Humble Inquiry
Humble Inquiry: The Gentle Art of Asking Instead of Telling
Edgar H Schein
Edgar Schein says we have a cultural issue. We like to tell people what we think, rather than asking them what they’re trying to tell us. Overall, especially in the world of information technology, I tend to agree. To counter this problem, he suggests that we perfect the art of the humble inquiry — redirecting our thinking from the immediate solution that comes to mind, or even from the question that was asked, and trying to get to the what the person we’re talking to is actually asking.
He gives numerous examples throughout the book; perhaps my favorite is of the person who asked stopped their car while he was doing yard work to ask directions to a particular street. Rather than answering, he asked where they were trying to get to. They were, in fact, off course for their original plan, but he directed them down a different path that got them there faster than if they’d turned around and found their way back to that original path. This is a perfect example of asking returning a specific question with a larger question — an authentic request for information that turns the situation from one of frustration into one of getting to the original goal.
The author also provides a useful section on how to differentiate between four kinds of questions, among which is the humble inquiry. There are times when it makes sense to lead someone we’re interacting with through questions, and others when it’s important to gain more information rather than making a decision. What’s never okay is the “gotcha question,” a form of attack in the guise of a question. While the author doesn’t cover it, it’s also never okay to hit someone with a complex question or a question predicated in a false dichotomy — two things that are all too common in our modern sound bite culture. He also gives a four part loop for decision making that’s very similar, but slightly different from, the OODA loop.
There are some parts of the book I didn’t find quite so useful, though, primarily in the last few chapters where the author moves off into psychology; much of this is based on views of the human psyche I don’t really accept, nor consider true (should I have phrased that in the form of a question?). Overall, though, this is a good, short, read on learning how to stop trying to take control of every situation, and instead learning to ask what the person who’s asking you really wants. I’d give it 4 stars, overall.
Review: The Craft of Research
The Craft of Research
Booth, Colomb, and Williamns
Engineers don’t often think of themselves as researchers. After all, what does writing a bit of code, or building a network design, have to do with research? Isn’t research something academic type folks do when they’re writing really long, and really boring, papers that no-one ever reads? If that’s what you really think, then you’ve come to the wrong blog this week. 🙂 In fact, I’d guess that a good many projects get off track, and a good number of engineering avenues aren’t explored, because people just don’t know how to — or don’t enjoy — research. Research is at the very heart of engineering.
Even if it’s never published, writing a research style paper can help you clarify and understand the issues you’re facing, and think through the options. Reading IETF drafts, software design specs, and many other documents engineers produce is depressing some times.
Can’t we do better? Of course we can. Read this book.
This book, while it does focus on the academic side of writing a research paper, is also a practical guide to how to think through the process of researching a project. The authors begin with a description of what research is, and why people “write it up.” The primary point they make here is that writing is thinking — a point with which I would completely agree. The process of building an outline and arguing a point, making certain to cover all counterpoints in the most complete way you can, is much like talking to the dummy on a more formal scale.
The second chapter dives into the mentality of writing — a very helpful overview of how to understand your audience, and then how to write to an audience. The authors take you through imagining yourself as the audience, understanding the role of the author (that’s you), and understanding the role of the reader. The third chapter probably won’t be as interesting to technical writers, because engineers are often handed their topic in an email or meeting. On the other hand, learning how to handle a topic is important. How deep do you need to go? What do you do if you find a “side question” that actually become more important than the question you were asked? These questions are addressed in this chapter and the next two.
Chapter five moves into sources — the authors provide an overview (not always as fine grained or as accurate as it could be) of various sources. They also provide a good section on thinking through alternate sources, and the problems with using people as sources. They are insistent on recording information about each source, even if you don’t think you’ll need it. I can’t recommend enough that you learn to use some form of note taking software such as OneNote for gathering information you’ve run across, even if it’s only loosely organized. I also agree with the authors here that documenting your sources is really important, even in technical projects. There’s nothing more frustrating than running across a really interesting tidbit of information and then not being able to find it again. I would recommend something like Zotero to help out with the documentation side of things.
The eighth chapter moves into structuring and making an argument. This might not seem to be important in the engineering world, but it’s actually crucial — from slides to technical specifications, imposing a logical (and narrative) structure on the information you’re presenting will dramatically help your readers understand you. Chapter nine is all about making claims — getting to the point where you make one specific point. Chapter ten discusses reasons and evidence.
The remainder of the book is focused around formatting, revising, and writing well — all worthy material, especially for engineers. This is a well written book with the lightest touch possible for a difficult to digest subject not many people know they should care about.
This is well worth reading — even if you are an engineer.
Review: Being Logical (Logical Thinking)
Being LogicalThis review is a little off the beaten path for most engineering blogs, perhaps — but I consider logic to be one of those “must have skills” for engineers. Being able to pull an argument apart, to understand the concept of a syllogism and the flow of logic, along with the various logical fallacies, adds greatly to your ability to write and process arguments for and against technologies and solutions (as well as in larger life). For some time, I’ve been looking for a concise description of the formal logic system I’ve encountered in philosophy a number of times, and a description of the many logical fallacies I’ve encountered in everyday life. Being Logical comes as close to fulfilling my desire for such a book as any I’ve encountered in my search.
Although this book is a trim 129 pages, it covers logic on a wide scale. The problem space is divided into five part; part one is preparing the mind for logic, which includes learning to observe, matching ideas to facts, matching words to ideas, and being mindful of the origin of ideas. It’s fair to note, at this point, that this first section also includes a small introduction to the correspondence theory of truth, the foundation of formal logic. Much of the modern progressive/post-modern project is based on overturning the correspondence theory of truth. The second part covers the basic principles of logic, including the concept of tracing an effect back through a cause, and the various ways in which we fail in this simple task.
The third part focuses in on the various logical constructions. Here the reader will find an explanation of the different pieces of a syllogism (the primary construction of logical arguments), and the importance of the truth of the terms (which refers back to the correspondence theory of truth) and the validity of the formal construction. There is a good bit of material here on the difference between statements of fact and value, and the place of conditional arguments, as well as useful reflections on the quality and quantity of the premise. This section contains a few helpful diagrams that illustrate the layout of logical arguments, as well. The fourth part dives into illogic, focusing on its sources, and the fifth part defines and names a number of logical fallacies (or rather mistakes in reasoning that invalidate an argument).
There are two things readers might find difficult about this book. First is the terse presentation; while examples are provided, a lot of information is provided in a very compact form. It can be difficult reading. Second, some people might object to the underlying assumption of the correspondence theory of truth, or question it from a number of angles. From a philosophical perspective, I happen to stand with the virtue ethic, which is closely tied to the correspondence theory, so I didn’t struggle with this aspect of the book at all — but readers more attuned to the post-modern mind might.
Logical thinking is a crucial point of engineering and thinking like an engineer. This book serves as a great, compact, readable introduction.
Recommended.
Review: Building Microservices
Building Microservices
Sam Newman
ISBN: 978-1-491-95035-7
Scale out where you can, scale up where you must.
Someone, somewhere, should probably start a collection of “where you can, where must” sayings, as these rules of thumb (thumbs were used by carpenters instead of a ruler to measure an inch, apparently) are important to remember, even if they’re imprecise. Route where you can, switch where you must — really refers to using layer 3 versus layer 2 networking as much as possible — for instance. Scaling out, from the perspective of network engineering, is all about repeatable modules, spine and leaf fabrics, and distribution of the control plane (didn’t think of that last one, did you?).
But what does scaling out mean in the application development world? It means splitting services into modular pieces which interact over the network. The ultimate goal of splitting services is to get to the microservice.
But what is a microservice?
To answer this question, you need to turn to the first chapter of Scaling Microservices, which says, “Microservices are small, autonomous services that work together.” Sam Newman, in the rest of the first chapter, explains the concept well, from a number of different angles, including the benefits of building microservices, the relationship between the service-oriented architecture, and other decomposition techniques that can be to pattern microservices. You won’t just learn about software development in reading this book, however — many of the principles and concepts are applicable to developing network designs, as well. For instance, the Single Responsibility Principle, which states —
Gather together those things that change for the same reason, and separate those things that change for different reasons.
If this sounds familiar, it should — it’s one form (with some modifications and additional precision) of the old rule of thumb — use failure domain boundaries to separate complexity from complexity.
In chapter two, the author examines the role of an architect in the world of software development. This is one of those “must read” chapters for anyone pondering what an architect is, and how the concept of architecture applies to information technology systems.
Thus, our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.
The network is one of those systems, and a system in its own right. We need to stop seeking the perfect network, and seek a good set of frameworks within which networking systems can be built. We’re not quite that mature of a field of study. Chapter 3 discusses one of my favorite topics, models, and how to use them to model services. The more models you can stuff into your head, the more you’ll be able to deal with unknown situations in the future.
Chapter 4 discusses integration, chapter 5 how to split a monolithic application into microservices (sounds a lot like deploying a new routing protocol, or deploying a new technology in an existing network), chapter 6 on deploying microservices. Chapter 7 returns to material that will be of more interest to network engineers (though you should read all of them!), working through models and systems for testing. One thing we’re not very good at in the networking world is testing, and this chapter is a trove of good concepts and ideas. Chapter 8 covers another useful topic, monitoring. Again, the author has a lot of good thoughts and models the network engineer can apply from the software development world.
Overall, this is a really good book for network engineers to read. Not only are there good ideas that can be directly applied to the world of network engineering, you’ll also learn something about building and deploying software in the modern business environment — and I’ve added this one to my 60 books page.
Review: The New IT
The New IT
Jill Dyche
Research has found that almost half of the CEOs described CIOs as being out of touch with the business and unable to understand how to apply IT in new ways. Over half also considered IT “a commodity service purchased as needed.”
So begins Jill Dyche in her examination of the relationship between IT and business. This statement sums up the entire point of this book: IT needs to find a way to be more engaged in the business world. Rather than just selling IT as a “commodity to be purchased,” IT leaders need to learn to show how IT can drive business value.
The author breaks the topic into three major parts — What’s Wrong with IT, Your IT Transformation Toolkit, and Leadership in the New IT. The first section, of course, outlines the litany of problems with IT in the business world today, from not having a seat at the table to being more about process and tools than actually driving business value. The second section contains a set of exercises that might (or might not — as in my case) apply to you and your role in IT leadership. These exercises involve answering questions in a “1-5” survey format, and then tallying a score that will give you some idea of where you stand on various roles and concepts in IT leadership. The final section provides more practical advice, such as the chapter on Fighting the Talent Wars, and Getting and Keeping a Seat at the Table. These chapters contain charts and surveys on how to best hire and keep talent, and how to build and keep trust among business peers.
The overall thrust of the book — as you might imagine — is that IT needs to take a more business centric view of technology work. The focus should be on getting the job done the business needs to do, rather than on “building resumes or playing with new and interesting tools.” The book has a number of interesting features, including infographics, checklists, IT leadership profiles, and “notes to the CEO” about their role in bringing IT into a larger role in the business. Each of these contributes to an easy and interesting read sitting at the intersection of IT and business from a decidedly business point of view.
The one thing to be aware of is the decidedly business point of view presented here. There is good insight into the business’ view of IT and the IT department it gives, but there are some rather ironic statements (see the quote I began this review with as an example) here and there from an engineer’s perspective — I’ll deal with these in later posts, as they deserve longer, more thought out, responses than a book review.
The Bottom Line: This is a good read if you want to understand the business perspective of IT. It may be difficult to apply the lessons to the average engineer, rather than the aspiring or current leader, but it’s still worth reading for the general ideas.
Time to Read: 3 hours
Note: The time to read is the time it took me, roughly speaking, to read this book. YMMV.