#Review – The Practice of Programming

In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles— simplicity, clarity, generality— that form the bedrock of good software.

Kernighan, Brian W.; Pike, Rob (1999-02-09). The Practice of Programming (Addison-Wesley Professional Computing Series) (p. ix). Pearson Education. Kindle Edition.

 

Programming is a craft. Some programmers refuse to acknowledge this, insisting instead that it’s a scientific or engineering discipline. There are certainly elements of that but anything that allows a human to place their own distinctive style on a made thing is a craft.

Bridges look a certain way because that’s how the physics make them look, not because the engineer was feeling whimsical that day. That’s why one bridge looks a lot like another. When a carpenter makes a bookshelf, it shares the same functionality with other bookshelves. However, there are a hundred individual decisions made by the carpenter during the design and creation process. A bookshelf is physics seasoned by art.

Two software applications may have similar functions but the underlying source code tells a different story. Anyone who reads or writes code knows that the programmer imposes their own personal style on the code in hundreds of different ways. From the use of a favorite decision loop to the design and implementation of a particular data structure, programmers have always found a way to express themselves in their work.

The Practice of Programming was written to bring programmers who are swimming in complexity back to their roots and help them regain perspective. Just to be clear, this is not a book that will teach you how to program. However, if you are learning to program or even if you’re a veteran coder, you’ll get something useful out of this text.

Despite this, Kernighan and Pike don’t romanticize the work of programming. Instead they show that by embracing (or re-embracing) the fundamental principles of coding, you can become a better, more productive programmer.

They start with a style guide, because clean, consistent code is easier to read, debug and maintain. Establishing and maintaining a consistent coding style frees up your higher brain functions for more complex decisions and problem solving.

Next we move on to algorithms and data structures. These building blocks of software should be familiar to all coders but the right algorithm choice can make the difference between a program that takes an hour versus one that takes seconds to produce the desired result.

The authors build on this foundational knowledge with discussions on design, interfaces (how to efficiently pass data), debugging, testing (which reduces debugging), performance, portability and end with a chapter on notation which includes a discussion of tools that will help you generate code automatically.

The writing is crisp and direct. Kernighan and Pike speak to you, programmer to programmer. They have decades of combined experience in the coding trenches and understand the problems you face every day, whether you’re doing an assignment for school or creating a business analytics solution for your business.

Advertisements

#Book Review – Code Reading

The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or formally used as a method for learning how to design and program.

 

Aspiring writers are always told to read as much as they can if they want to become better writers. As Dave Thomas points out in his foreword to Diomidis Spinellis’ Code Reading, aspiring programmers almost never get this advice. By code, of course, I mean the program source code, the fundamental recipe for any piece of software.

Imagine that you’re taking a writing course. You get assignment after assignment – persuasive essays, memos, poetry, research papers or prose. Now imagine that you have to do every one of these assignments from scratch, without any examples. You have to work everything out yourself.

This is the traditional method of teaching programming. I know because I used to teach programming classes.

Code Reading is both refreshing and an eye-opener. Not only does Spinellis present a solid case for the habit of reading program source code, he also fills his book with code examples, complete with commentary. Though the examples are mainly from Java and C, the lessons learned can be applied to any programming language.

Just to be clear, the code presented is not from the toy examples found in programming textbooks. This is material from real, working software projects. The book covers major programming topics and even includes analysis of a complete, working program. Spinellis gives tips and techniques for the novice code reader to aid them in developing their skills.

From my own experience, reading code can be very educational, even entertaining. Every programmer tries to put their own personal stamp on their work and part of the fun is seeing the human mind behind the algorithms.

For example, I was teaching game software development and wanted to get my students some practice in reading code. We downloaded the source code for BZFlag, a tank game based on the video game BattleZone combined with Capture the Flag. It’s a fun, cross-platform game that you can play solo or over the Internet with teams.

There was one particular feature in which I was interested. During play, you can set your tank to AutoPilot mode and let it play for you. This makes a nice change from having to pause your game whenever you have to get up and take care of business.

We grovelled through the source code files for a bit and I finally found the sections having to do with AutoPilot. As I read them, I spotted some code that looked very intriguing but was never actually called by any other part of the program. It looked like someone was trying to build a heuristic system for the AutoPilot mode. In short, it was meant to have the program build a solution starting with the goal and working its way backwards. It was very clever and had a lot of potential. I could add see why it hadn’t been  implemented due to the inherent complexity of the method.

The fact that the code was just left there, unfinished, was fascinating. When I saw that code, I put myself in the mind of that programmer. I’ve also had coding ideas that got stuck in blind alleys. But here was someone like me, trying to solve a problem in an interesting way and failing that, leaving a note for the explorers to come after in hopes that they would ultimately succeed where he did not.

This book shouldn’t just be on any programmer’s reference shelf, it should also be the basis of at least one undergraduate programming class.


Spinellis, Diomidis. Code reading: the open source perspective. Addison-Wesley Professional, 2003.

#Review – The New Hacker’s Dictionary

bogosity /boh-go’s*-tee/ n.

 

  1. [orig. CMU, now very common] The degree to which something is bogus. Bogosity is measured with a bogometer; in a seminar, when a speaker says something bogus, a listener might raise his hand and say “My bogometer just triggered”. More extremely, “You just pinned my bogometer” means you just said or did something so outrageously bogus that it is off the scale, pinning the bogometer needle at the highest possible reading (one might also say “You just redlined my bogometer”). The agreed-upon unit of bogosity is the microLenat. 2. The potential field generated by a bogon flux; see quantum bogodynamics. See also bogon flux, bogon filter, bogus.”

 

I love words. I’m always looking for new phrases and jargon, the more evocative the better. After I read Steven Levy’s Hackers, one of the things that stuck with me was how this group had developed their own language.

Every field of expertise has its own jargon. For hackers, though, English is just another programming language, just with looser rules. It’s a system. Hackers explore and manipulate systems, either to achieve a specific goal, see what happens or just to have some fun.

The New Hacker’s Dictionary originated in 1975 at Stanford as a simple file maintained by Raphael Finkel, collecting hacker jargon from various branches of the community. Like any language, ‘hacker-speak’ has dialects. The file was copied around the community, each group adding their own entries to what was becoming a shared history of the hacker culture. Eventually it was collected and published by M.I.T. Press and that’s when I got my hands on a copy.

Normally you don’t read a dictionary for fun, but this one is different. It’s a snapshot of a period of time that transformed not only my own personal and professional life but that of the world.

Consider this. The year the Jargon File was created, the very first personal computer was offered for sale.

It was the MITS Altair.

It came with 256 bytes of memory (expandable to 64K), had no keyboard or monitor and a single data bus. You had to key in your programs in low-level assembler code by flipping switches on the front panel one word at a time.

It sold as a kit for $297 (the case was extra).

Oh, yeah, I almost forgot. Microsoft got their start licensing software for the MITS Altair.

The year the Jargon File was finally published, more email was sent than postal mail in the United States and an IBM computer named Deep Blue became the first machine to beat a chess grandmaster.

The book includes a pronunciation guide, a guide to hacker writing and speaking style, a section describing hacker folklore and a guide to ‘J. Random Hacker’, which serves as a sort of spotter’s guide.

The words and phrases themselves range from layered and complex to playful and the book includes cartoons by Guy L. Steele, co-author and noted computer scientist.


Reference: Raymond, Eric S. The new hacker’s dictionary. Eric S Raymond. M.I.T. Press, 1996.

#Review – The Mythical Man-Month

“There is no Silver Bullet.”

In 2008 IBM did a study of large IT projects that showed that nearly 60 percent of them fail. For the majority of these, the problem was people.

This isn’t news.

In 1975, Fred Brooks published The Mythical Man-Month based on his experience as an IBM project manager and as a world-class computer scientist and software engineer. It detailed the multiple reasons for the high failure rate of I.T. projects and proposed solutions.

I bought my copy in the early 90’s. I was working at AT&T doing I.T. support and I was volunteered for an I.T. rearchitecture. It was a large project, involving the re-design of an entire call center and included hardware and software upgrades as well as business process re-engineering. It was my first project and I wanted to know more about this process so, as I usually do, I bought a book.

The title comes from the then-standard practice of measuring the size of a job. So if I estimated a particular project at twelve man-months, that would mean that one man could do it in a year, six in half a year and if you gave me a team of twenty-four I’d finish it in two weeks.

The problem, Brooks proposed, was that while the man-month is a good estimate for project cost, it’s terrible for measuring the time and resources needed to complete the task. As he himself put it:

The bearing of a child takes nine months, no matter how many women are assigned.

Despite the complexity of the topic, The Mythical Man-Month is surprisingly readable and contains valuable insights culled from Brooks’ decades of experience. He details how to assemble a successful project team, best practices for inter-project communications and how to manage project documentation. The book was reprinted to celebrate its twentieth anniversary and, with some modifications to allow for technological change it’s still relevant today.


Reference: Brooks, Frederick P. The mythical man-month. Reading, MA: Addison-Wesley, 1975.