Programmer Musings

Review of Information Dashboard Design

Information Dashboard Design
Stephen Few
O'Reilly, 2006

This book covers a growing trend in user interfaces, the dashboard. The purpose of a dashboard is to display important information clearly and concisely. The author makes a point of stating that a dashboard must convey information you need to act on. This generates a shift in viewpoint from displaying data to helping focus attention where it is needed.

A large portion of this book involves examples (both good and bad) of dashboards. The author analyzes each example to explain what works and what does not. Along the way, he explains principles of visual design that can help you produce an effective dashboard. We learn that pie charts are usually not very effective, that flashy interfaces don't usually convey information well, and that extra pixels can ruin a good dashboard. He also reinforces the importance of the placement of data on the display as well as grouping and displaying data for use rather than for glitz.

The examples in the book cover a wide range of styles from mostly text to mostly graphical. Colorful displays are contrasted with subdued presentations. Cool gauges, traffic lights, maps, 3D pie charts, and numerous graphs are all compared and examined. Some of the examples are visually stunning. After Few finishes analyzing their flaws, you may be stunned in a different way.

One of my weak areas in software development is UI design. Some of the advice in this book may be obvious to someone with more visual arts background, for me it was really an eye-opener. As I got farther along in the book I found that even I was able to spot some of the flaws in the examples. I don't know that I learned enough to make a really good dashboard on my own, but I believe I now have a better grasp of what not to do.

If you find yourself in the position of needing to design or develop a dashboard or would just like to know something about this form of display, I would highly recommend this book.

Thinking About Object Lifetime

Several times in the last few years, I have written about the subject of memory management, garbage collection, and object lifetime. Some of essays I've written on this subject include:

• The Semantics of Garbage Collection
• More Thoughts on Resource Recovery
• Other Resource Recovery Approaches
• Resource Management Revisited

Recently, I was thinking about this issue again and had a slightly different insight into my favorite argument about garbage collection. I have often said that one of the things I don't like about the standard mark-and-sweep approach to GC is that it usually disregards object lifetime. I've normally seen the loss of defined object lifetime is a problem with GC. I've argued before that this loss removes a very important tool from the programmer's toolbox.

However, I recently began to consider another aspect of object lifetime that I had previously overlooked. Even in a language that supports GC, being aware of object lifetime is still worthwhile.

Memory in non-Garbage Collected Languages

In languages like C++, that support defined construction and destruction of objects, the lifetime of an object is directly connected to the point when the constructor and destructor is called by the runtime system. A good C++ programmer should think how an object should be created and destroyed. The programmer uses object lifetime to determine what needs to happen at the beginning and end of an object's life.

Defining the length of time the object lives also requires a little thought. If the object only needs to live a short period of time in one function, a stack object is appropriate. In other cases, a smart pointer can be used to constrain the lifetime of an object in well-defined ways.

A good C++ programmer thinks carefully about object lifetime and as a consequence has little problem with memory leaks. If the C++ programmer does not think about object lifetime issues, memory leaks abound.

Memory in Garbage Collected Languages

Memory leaks are not supposed to be possible in GCed languages. However, I have seen several cases of Java programs that leaked memory. In one sense, these are not really leaks, since the memory is referenced somewhere. But, in another sense, they are leaks because the memory usage of the program is growing unexpectedly. In many of these cases, the problem is that the programmer has forgotten about the object and did not tell the language to forget the object.

Even in a GCed language like Java, memory leaks are caused by not thinking about object lifetime. If the programmer attaches an object to a longer-lived object or container and forgets to remove it when the object is no longer needed, the object has effectively leaked. By not properly discarding references when the program is finished with them, the programmer has generated memory leaks just as surely as if the language did not support GC. It's not an issue for short-lived objects created and discarded within a short stretch of code. But, then leaks aren't possible with stack-based objects either.

Conclusion

Whether your language of choice supports GC or not, thinking about object lifetime will help you avoid memory problems. It may also help you avoid leaking other resources by making certain you are clear about when the resources are needed.

Review of Managing Humans

Managing Humans
Michael Lopp
Apress, 2007

Michael Lopp (also known as Rands) describes his take on managing software people. This book is very different from the few other management books I've read. Part of the difference is that Lopp writes all of his examples as fiction. He admits this at the beginning. Rather than tell embarrassing tales about people he has managed, he creates some fictional employees based on his experiences and uses them in equally fictional examples.

This could come across as unrealistic or cartoonish, but Lopp manages to pull it off. Like some of the best Dilbert strips, you have to admit that if these stories aren't true, they should be. If you've worked in this industry for any length of time, you've probably met (or been) several of these characters.

Another odd point for me is that Lopp seems to truly like what he does. This book is not about helping a non-manager survive in a management role. This book is not about a necessary stop at first-line manager while climbing the corporate ladder. This book is not even about keeping those workers in line, so you can get the big bonuses. This book is written by someone who really seems to enjoy the challenges of working as a software engineering manager and who wants to explain how you could like it too.

In the first section, Lopp does a pretty good job of explaining what you need to know about your manager and what he needs to know about you. He explains that most managers aren't actually evil. He also spends a bit of time explaining managementese.

Lopp also explains how managers lose it, the importance of saying no, and the real importance of information flow. He talks about pride and panic, resigning, layoffs, and hiring. He also identifies several special kinds of personalities that you will encounter at work and how to learn to listen and talk with these personalities without going mad.

Overall, I think this book is the best document I have read on managing in the software industry. Granted, I haven't read a large number of these, but it seems to make sense even to someone with little interest in a management position. More importantly, I think it make make me a better employee, by making it easier to understand my managers.

If you are a new software manager or you are looking to make the move into management, this book is a definite must-read. If you would honestly like to know what in the world your manager does even if you are not interested in doing it yourself, I would also recommend reading the book.