Wouldn't it be great if you could get everything you ever wanted, everything you ever dreamed of, simply by wishing for it really hard? According to Rhonda Byrne, you can.

In her bestselling book "The Secret", Ms. Byrne and a few similar-thinking people advise that the path to success is to visualize what you want. Rhonda asserts that our thoughts are energy and this energy is emitted out of our brains and across the universe. The "Secret" of the title is that "like attracts like". In other words, whatever you think about and wish for will come true, whether you think positive thoughts or negative thoughts. Our mind sends out impulses of energy and attracts back to us whatever we are thinking. If we think about our debt, for example, more bills will arrive in the mail; however, if we shift our thinking and visualize money coming in, checks will appear in our mailbox in place of those bills. The universe will simply read our thoughts and transform itself accordingly.

She compares the universe to the story of the magic genie that comes out of the magic lamp proclaiming "Your wish is my command". The universe, she insists, is much like this genie; ready to grant our every wish as long as we wish it hard enough. Byrne offers no explanation why this should occur and urges the reader not to question how, but instead focus on positive thoughts, which, she insists, are the powerful force that will change your life.

If I sound skeptical, it's not because I reject all of Ms. Byrne's ideas. I believe in the power of a positive mental attitude; I believe that the secret to happiness is the belief that we can change our life for the better; I believe that optimism can contribute to a healthy life; and I have observed that we tend to attack our goals more effectively when we are enthusiastic about them.

But I also have learned that positive thinking is generally not sufficient for success. We also need a plan to achieve our goals. And often we need to work hard to execute that plan. Plans and hard work are not part of Ms. Byrne's Secret. For her and her followers, it's all about visualizing that new car or an awesome life partner or a cure for your disease. Wish it really hard and you will mysteriously get it.

Byrne does not cite any studies or indeed provide any real evidence of her theories, but she does quote a lot of people with impressive titles like "Philosopher", "Metaphysicist", and "Visionary". She also provides a handful of anecdotes to support her ideas. However, most of the people in these anecdotes are either unnamed or are the same visionaries and philosophers who contributed to her book.

If you've already seen the film of the same name, you won't need to read the book - it's basically a transcript of the movie. The difference is that the book adds credibility because it is printed on paper the color of aged parchment and the movie provides credibility by allowing you to see that many of Ms. Byrne’s supporters look and act like television evangelists. Both the book and the movie have lots of calligraphy, so you know they are serious.

If you want to take the first step toward change, I recommend you include positive thinking as part of your strategy. But if you are serious about changing your life and achieving your goals, I suggest you look for a self-help book that is closer to the opposite edge of the fantasy-reality continuum.

I, Steve sounds like an autobiography written by the late Apple founder Steve Jobs. The title is eerily similar to the the autobiography title of Steve's former partner, Steve Wozniak.

In fact, I, Steve is a collection of quotes by the tech visionary. gathered together into a slim paperback and organized by category. It was obviously thrown together quickly after the death of Mr. Jobs, and probably compiled almost entirely from online searching.

Still, there is a lot of wisdom in this collection. Jobs was a visionary and his company changed both the computer market and the electronic devices market. So, it's not surprising that he revealed this vision in interviews, speeches, and conversation.

The following quote from a 1999 Time magazine interview could serve as well as any mission statement.
"The roots of Apple were to build computers for people, not for corporations. The world doesn't need another Dell or Compaq."

Jobs's famous quote "Real artists ship" appears several times in the book - In part because he was fond of repeating it and in part because it is appropriate to multiple categories.

Although you'll find some inspiration among Jobs's words of wisdom, the lack of context make this book little more than a trivia book. Still, Jobs's words were entertaining and inspiring and you could do worse for bathroom reading.

Azure In Action by Brian Prince and Chris Hay has something for everyone. It provides a good overview of the use cases for Windows Azure and a high-level overview of the Azure architecture, which is useful for those new to the platform. It also provides many in-depth examples of Azure features, such as web roles, worker roles, and storage options.

The book also benefits from the light-hearted style of Prince and Ray, who are as entertaining in print as they are in person.

The only downside is that newer Azure features are not covered in this book and Microsoft is adding new features at a startling rate. As far as I know, no updated edition is in the works to cover these new features.

Still, the book remains relevant because of its focus on the uses of cloud computing and on the still-relevant core features.

If you are new to Windows Azure, this book is a good starting point.

JavaScript’s popularity proves how useful people have found the language. Novices use it to add simple validations to web forms, while advanced build amazing applications with JavaScript.

Yet, for all its utility, many look at JavaScript with disdain and fear, pointing to dangerous features and to the difficult of dealing with the browser's Document Object Model.

In JavaScript: The Good Parts, Douglas Crockford distinguishes between the good features of JavaScript that make it and elegant and powerful language; and the bad parts that make it dangerous and difficult to understand. Crockford’s message is to use the good parts and avoid the bad parts and stop fearing JavaScript.

According to Crockford, most people misunderstand JavaScript and so they misuse it; then, they complain about the language.

Crockford acknowledges that the designers of JavaScript made some mistakes (global variables, for example), but that there are enough good features of the language to make it appealing to a wide range of users writing a wide range of applications. He notes that JavaScript succeeded as a platform for creating client code for the web – something that that the more powerful Java language attempted and failed badly – and that this proves JavaScript’s power.

Applications will be better and developers happier, notes Crockford, if developers avoid the bad parts of the language. For example, always use the "===" operator, which returns what most users expect because it doesn't do any type coercion. Avoid the confusion of the "==" operator, Crockford recommends.

Crockford's style is concise and straightforward. At fewer than 200 pages, the book has no room for distractions. Regular Expressions are presented and described and examples are shown how to use them. Crockford clearly describes Closures, a feature that is likely new to many developers; and he spells out how callbacks are implemented in JavaScript.

Before reading this book, I was unaware of implied semicolons in JavaScript and whey they can be dangerous. Crockford spelled out the dangers and how to avoid them very clearly.

JavaScript can be a great language if you confine your programs to using the best parts of the language and steer clear of most of the dangerous features. This book will help distinguish the two.

If you are new to performance and load testing, you need two things: knowledge of testing practices and knowledge of testing tools. .NET Performance Testing and Optimization: The Complete Guide by Paul Glavich and Chris Farrell provides both of these.

.NET Performance Testing and Optimization provides a solid overview of good testing practices, as well as practical information on how to use various commercial testing tools that are currently available.

The first three chapters cover principles of testing, such as which metrics you can measure, what information each metric provides, and when to care about each metric.

Glavich and Farrell describe the different types of tests and the goals of each. Performance Testing, for example, measures the speed at which an application responds to user input and events. Load Testing measures the number of concurrent users an application can reasonably support. Although they are often confused, the goals are different and the important metrics for each are different.

The rest of the book describes in detail various types of tests you can perform. Glavich and Farrell even provide step-by-step instructions to perform these tests with popular commercial products.

For those new to performance testing, for those needing a refresher on performance testing, or for those who want to know how to use commercial products to perform performance testing, .NET Performance Testing and Optimization  is a good source of information.

Dr. Greg Low has been running a technical user group for years. In Building Technical User Communities, he shares what he has learned - what works; what doesn't work; and advice that may or may not fit your group.

As a longtime user group contributor and leader, I had already considered many of his recommendations, but I found most of them to be solid advice. In fact, at my group - The Great Lakes Area .NET Users Group in Southfield, MI - we were already doing many of the things that contained in this book.

For example, we found that members appreciate a consistent meeting place and time for our group. We have also used our group as an opportunity for new speakers to build their skills in a low-risk environment.

Like Dr. Low, I have found the best way to grow a group's attendance is by word of mouth - get to other user groups and technical events in the area and promote your group; and encourage your members to invite their friends and co-workers to the next meeting.

You don't need to take every bit of advice. For example, Dr. Low recommends 2 speakers per meeting, while my group has been successful with just one.

A month after the expiration of my term as user group president may not be the perfect time to read a book on how to lead a user group. But it's a good time to evaluate such a book.

If you are part of the leadership of a technical user group or you are considering forming your own group, an evening spent with this guide will give insight into what can make it successful.

Restful Web Services Cookbook by Subbu Allamaraju

The format of Restful Web Services Cookbook is different than I’m used to. The book presents ideas in the form of a problem, a solution, and a discussion of the solution. It starts with simple concepts like HTTP verbs (GET, POST, PUT, etc.), and moves onto more complex topics, such as content negotiation and sending queries via HTTP.

Most eye-opening for me is the concept of providing in the data sent to the client links to perform related actions on the data, such as updating the record or rolling back changes to a previous version.

In my career, I typically focus on the tools of software development. This book ignored the tools to create and consume web services and focused on the format of the messages passed. It got me thinking at a lower level – about message headers and HTTP verbs – than I am used to thinking.

One hast to get past the fact that Allamaraju does not provide code for generating the requests and responses he describes. He does so in order to keep it technology-neutral and language-neutral. The reader has to apply the concepts to their own development skills in order to implement these recipes.

Restful Web Services Cookbook gave me new insight into the workings of HTTP. It took me out of my comfort zone and taught me a lot.

It has been almost a decade since I first learned C#. It didn’t take me long to become productive in this language; but years later, I am still uncovering its secrets. There are two reasons for this:

1. C# is a relatively complex language and new features are added with each release. There is a lot to learn
2. In many cases, C# offers multiple ways to accomplish the same task and it’s not always obvious which way is best for my project.

In Effective C#, 2nd Edition, Bill Wagner attempts to demystify C# by explaining much of the inner workings of the language and by providing specific advice points to improve your coding.

The book assumes a basic understanding of C# syntax. It builds on this understanding in two ways:

1. Explaining the implementation details of the language
2. Providing advice on how to use the language and the .Net libraries in your coding.

The second edition of this book includes new features introduced in C# 3.0 and 4.0, such as lambda expressions and LINQ.

The book is split into 50 chapters and each chapter advises developers on a specific coding preference. Wagner backs up his advice with an explanation of the inner workings of the C# language. Among the questions that Wagner answers are:

• What is the difference between readonly and const and which one should I use and why?
• What new C# feature reduces the need for multiple overloads?
• When and how do I need to explicitly dispose of objects?
• What does it mean for a variable to be statically typed as a dynamic variable? Does that even make sense?

I learned something new in nearly every chapter. Some chapters shed more light on topics that I thought I knew well. Other chapters introduced me to concepts about which I knew very little. And a few chapters contained information so complex that my head began to hurt (I'm looking at you, IDynamicMetaObjectProvider).

With 50 chapters of solid advance and concise explanations, everyone beyond a beginner level in C# can benefit from this book.

You might think that full-color illustrations would make very little difference in a technical book.

But  Beginning JavaScript and CSS Development with jQuery by Richard York focuses so much on user interfaces that the added color makes the samples more clear. When the author lists code to change the color of a paragraph, the illustration shows the new and old colors to drive home the concept.

York starts with the basics of jQuery – selecting elements on a page and applying styles dynamically – and moves progressively into more advanced topics, such as making Ajax calls and accessing the jQuery API. He devotes about a third of the book to jQueryUI, a library that contains controls designed to build rich, interactive web interfaces without the need for a lot of code.

York explains the challenges inherent in developing applications with Javascript (the need code to different Document Object Models for each browser) and how jQuery addresses this by providing a single programming model that abstracts away the different browser DOMS.

The book is filled with examples, showing the HTML, CSS and jQuery demonstrating each point. You can read/copy these from the book or download them from the Wrox site.

This book is aimed at someone with experience in HTML and CSS, but little to no Javascript or jQuery knowledge. For those just getting started in jQuery this is an easy to follow book where you can learn the concepts and quickly become productive.

It’s no secret that software developers, managers and analysts do a poor job estimating projects. Few IT projects complete within the time they are estimated and far more go over the original estimate than under it.

Steve McConnell knows how difficult estimation can be His 2006 book Software Estimation is subtitled Demystifying the Black Art.

Developing reasonable estimates of software projects may not be a black art, but it does cause problems and most people fail at it for a variety of reasons.

McConnell refers to estimation as an art, not because it has no basis in science, but because formulas don't tell the whole story. Experience and difficult-to-measure inputs are required to generate a complete estimate. And even then, you may still get it wrong.

When McConell lists sources of estimation error (subjectivity, missing tasks, unwarranted optimism, excess precision), it's startling how many of those factors I have experienced or contributed in my own career.

The author provides various methods for creating an estimate and guidance on improving the accuracy of your estimates. Among his advice is:

• Base your estimates on something you can measure - preferably historical data on similar projects in your own organization. Estimates based on measurable data are far superior to those based on subjective criteria.
• Estimates are never precise (they're not called "exactimates"). Present estimates as ranges and don't include more significant digits than your inputs can justify.
• If possible, get effort estimates from those who will actually perform the work. Developers vary in how quickly they can accomplish a given task - sometimes that variance is in orders of magnitude.

If part of your job includes estimating software projects, this is an essential book to guide you. Like most of McConnell’s books, I recommend it.

The Elements of Style by William Strunk Jr and E.B. White changed my life.

In 1919, E.B. White was a student in William Strunk Jr's Cornell English class. The course textbook - written by Strunk a year earlier - impressed White enough that he decided to revise and expand it 40 years later.

While Strunk's version focused primarily on rules of proper English grammar, White added sections on writing style.

White argued that writing can be grammatically correct but poor quality, if it lacks good style. In his revised edition, White established guidelines by which a writer can improve his or her writing style.

The book has been revised several times over the years as the English language and the audience have changed and evolved.

The major points of the Elements of Style are

• Know the basic rules of grammar. Be aware of the most common errors of grammar and spelling.
• Tell your story in a clear and straightforward manner. The message is more important than the style.
• Be Concise. Wasted words dilute your writing.
• Excessive adjectives, adverbs and qualifiers detract from your message. Eliminate them.
• Choose established usage, before deviating

Most of these rules can be broken, White tells us.

The Elements of Style is often criticized because many great writers ignore this book's advice. But White does not claim to preach dogma: He provides guidelines that will improve most writing.

But we should understand the rules that we are breaking and we should break them for good reason.

If you do any writing in English, you will benefit from this book. At less than a hundred pages, the time investment is small but it packs more information than much larger books.

This is a book that I read every few years because it reminds me of the power of strong, concise writing.

Interest in F# has risen dramatically with the release of Visual Studio 2010 and Microsoft's decision to include this language with this product.  Many of us are scrambling to understand this new language and how it relates to our software projects.

F# is a functional language, which means that it focuses on giving developers the ability to create functions that consistently return the same value, given the same inputs. It does so by discouraging mutability in its language constructs, thus minimizing side effects that can alter state from one call to the next.

Chris Smith's book Programming F# provides an introduction to and an overview of this language. Because so many of the constructs are foreign, this book can be a bit overwhelming - particularly Chapter 2, which quickly introduces many of the language constructs of F#.

But Smith brings it together after pushing through the language details. He goes through the basics of functional programming; then compares it to imperative programming, showing how you can implement either style using F#. He follows with a discussion of object-oriented programming and its relevance to F# (it is a key to allowing F# programs to interact with programs written in other .Net languages).

The book is filled with examples to illustrate the points made. If you are new to F#, Programming F# is a good book to get you started with the language.

What I like about Paul Kimmel's LINQ Unleashed for C# is that he does not rush into explaining LINQ. Before explaining LINQ, Kimmel explains the new technologies that make LINQ possible.

He walks the reader through anonymous types, type initialization, extension methods, the yield return statement, lambda expressions, and closures - all features that were introduced in C#3.0 - before explaining how each of these features makes LINQ possible.

After building up to it, Kimmel steps through the syntax of LINQ, providing numerous code examples.

He begins with syntax to all implementations of LINQ; then dives into more detail about the major LINQ implementations: LINQ to SQL, LINQ to Objects, and LINQ to XML. In each section, he provides numerous helpful samples.

When I first opened this book, I was new to LINQ (Language Integrated Query) and had no grasp of how it works. This book got me up to speed. I recommend it for anyone learning LINQ.

Like most statistical measurements of large groups, the success of people in a given population usually forms a normal distribution or "bell curve". In other words, most people fall at or near the average level of success; and as we move further above and below the average, fewer and fewer people appear at each level until the number approaches zero far above and below the average.

But some people fall well outside the boundaries predicted by the normal distribution. These people are outliers.

In his book "Outliers", Malcolm Gladwell is primarily concerned with those outliers who excel far beyond the level expected. These are intellectual geniuses and musical prodigies and world-class athletes who achieve great success.

Becoming an outlier takes talent and hard work - a lot of hard work: 10,000 hours of dedicated practice, according to Gladwell.  For example, the Beatles owe their success in large part to the fact that they performed 8-12 hours a day for 2 years at the clubs in Hamburg, Germany, allowing them a chance to perfect their craft before they recorded their first hit records.

But Gladwell insists that enormous success takes more than talent and hard work. It takes luck. And that luck sometimes follows measurable patterns and those patterns can be predicted.

As evidence, he points to birth dates as a major factor in the success of many outliers. Bill Gates, Paul Allen and Steve Jobs were born within months of each other; Of the 75% richest people in history, 14 were born in the United States between 1831 and 1840; and the vast majority of elite Canadian hockey players were born during the first half of the year.

He then explains reasons why something as seemingly arbitrary as a birth date would affect one's chance at extreme success. In each case, he presents a plausible explanation of the cause and effect. Canadian hockey players born in January, for example, tend to be placed in the same league as the much younger players born in December of the same year. At a very young age, this can be a huge advantage, so the older, bigger, stronger January-born athletes tend to dominate the less mature December-born players. As the stronger kids stand out more, they get picked for the better leagues, where they receive superior instruction and more practice time (making it more likely they will be able to put in 10,000 hours of practice before adulthood).

Just as talent and hard work alone will not guarantee success, neither will lucky circumstances. But these things improve one's chances - sometimes drastically.  Not all Canadian hockey players born in January make it to the NHL. But almost none of those born in December do.

Gladwell's case studies are very interesting and very plausible. He supports his hypotheses primarily with anecdotal evidence. But he supplies enough statistics to support his conclusions.

These seemingly random factors are often predictable, so it is possible to modify our behavior and increase our chances at great success. Some of them (month of birth, for example) are beyond our own control; while others (year of birth, are only known to be success factors later on), so it's difficult to modify all our behavior.

Outliers challenges the notion that people achieve great success solely through talent and hard work. Outliers is an interesting study of his findings and worth reading.

I began reading Agile Principles, Patterns and Practices in C# by Robert C Martin and Micah Martin after a friend recommended the chapters on pair programming.  My friend was right, of course. The Martins not only decribed pair programming but included an entertaining script of two developers pairing on a programming problem.

But, as I dove deeper into this book, I found a wealth of other information.

The book begins with a section on agile development, defining some basic terms and concepts recommended practices. It follows with a detailed section on good design practice. This second section is the most interesting, as it describes the famous SOLID principles. SOLID is an acronym for a set of good design practices:

S=Single Responsibility Principle: Each class should serve only one purpose and have only one reason to change.
O=Open-Close Principle: Classes should be open for extension but closed for modification
L=Liskov Substitution Principle: It should always be possible to substitute a derived class with its base class
I=Interface Segregation Principle: Interfaces implemented by a class are defined by the client objects that use that class; a class should implement a separate interface for each client that calls it.
D=Dependency Inversion Principle: To maintain flexibility, you should write code that depends on abstractions, such as interfaces.

Next, the authors present an overview of Unified Markup Language (UML), a graphical language used to describe software designs and requirements. Common UML diagrams and shapes are described and the author offers opinions of which ones are most useful and when to best use them.

The last half of the book is a case study of a Payroll System in which the authors use examples to illustrate the concepts introduced in the first half of the book.

Although C# is included in the title, the book does not focus on C# and almost none of the concepts are specific to any particular language. All the code examples are in C#, which makes it a bit more accessible if that is your strongest language.

The book is filled with lots of information and good advice. For example, the authors recommend an iterative approach to writing software, a test-first approach to development and encourage developers to refactoring their code frequently.

Whether you read all of Agile Principles, Patterns and Practices in C# or pick through the sections of interest, you will benefit from this book.

You could start at the beginning and read all the way through Windows Server 2008 R2 Administration Instant Reference by Matt Hester and Chris Henley. Part 1 of the book of the book ("Getting Started") walks the reader through planning, installing and upgrading the operating system, while subsequent sections dive into details about specific areas of the software.

But a more reasonable approach is to open to the section on which you are working today. Each chapter is structured so that you can dig into the detail you need. Each topic begins with an explanation of concepts and definitions of key terms. This part is critical for someone like me, who doesn't spend his days managing servers. Experienced administrators may skip this section and jump to the detailed explanations of how to use and configure each feature of Windows Server 2008 R2. Basic functionality is described first, followed by more advanced features.

A section on Active Directory, for example, begins with a description of built-in groups, followed by a description of custom users and groups and how rights are granted. After establishing these basics, the author describes how to use Active Directory to manage groups, users and rights and how to configure this in Windows Server.

Hester and Henley write in a clear, concise style that simplifies everything they describe. Step-by-step instructions are amplified by screen shots.

The smaller dimensions of the book make it fit easily into a laptop bag, despite the 500+ pages of text.

This is a solid book for a full- or part-time network administrator to keep on hand for a quick reference or for a more detailed look into important concepts of Windows Server.

Official Book site

Complexity is the Enemy! 

This is the message driven home repeatedly by Roger Sessions in his book Simple Architectures for Complex Enterprises. 

Sessions recommends tackling a complex enterprise architecture by identifying the subcomponents of a complex system and dividing that system into autonomous subsystems. He refers to these subsystems as Autonomous Business Capabilities (ABCs) and the process of dividing them as a Simple Iterative Process (SIP).  

Before describing how to approach this process, Sessions presents a mathematical proof that subdividing a complex system into a set of subsystems reduces the complexity of the system as a whole. This seems intuitive to many of us, but the mathematics allow us to be more forceful in our commitment to this process. The mathematics is relatively simple (nothing beyond high school math) and he even recommends training team members in this mathematics before beginning any SIP.

A large part of an Enterprise Architect's job is to define the optimal way to partition the complex system. By applying mathematics to his model, he removes the emotions that so often dictate how a project is broken up.

The process of splitting a complex system into appropriate subsystem isn't overwhelming, but it is critical to managing complexity. According to Sessions, Each ABC should contain only elements that relate to one another; and the elements of one ABC should not relate directly to or communicate directly with any element in another ABC. Once partitioned, each ABC should be roughly the same size, although it is possible to split a subsystem further into sub-subsystems. It is also critical that communication between each subsystem take place only at a few clearly-defined points.

If this sounds like a recipe for Service Oriented Architecture, this is no coincidence. Sessions concludes his book with recommendations on moving from business partitions (ABCs) to software partitions, which he describes as "fortresses". These software partitions follow many of the same rules as ABCs created with the SIP, so making this transition is straightforward.

This is a good book for anyone who aspires to be an Architect (Enterprise or otherwise) and wants to apply a systematic approach to managing complexity.

Microsoft ASP.Net MVC (aka "MVC") is a new framework from Microsoft designed to encourage loose coupling between the user interface and the data layer of a web application. With MVC, an application is logically divided into the Model (the data), the View (the user interface) and the Controller (code to retrieve and manipulate data before passing it to the View). This framework makes it nearly impossible to add business logic (or any code for that matter) to the UI layer; Business logic in an MVC application belongs in either the Model or the Controller. MVC allows for greater separation of concerns, more control over the HTML output and easier unit testing of a greater percentage of your code.

Professional ASP.NET MVC 1.0 by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie describes the framework, how to use it, and how to exploit these advantages.

A significant part (about 40% of the text) of this book can be downloaded free. Chapter 1 - the free download written by Microsoft VP and cyber-celebrity Scott Guthrie - describes an ASP.NET MVC application called 'Nerd Dinner'.  This is the chapter I spent the most time on. I used Nerd Dinner as a model to build my own MVC application, striving to understand why the code was written as it was and how the framework was used. For me, this was the most useful part of the book.

This is not to say that the rest of the book is useless - It was very informative. I especially liked the chapters that dove deeper into explaining the Routing Engine, the Controllers and the Views. These chapters weren't comprehensive enough to be a definitive reference, but they were clear and concisse and I learned the flexibility of this framework and alternative ways to use it.

Other chapters describe how to use JQuery and Ajax to make MVC applications more dynamic and visually appealing. The authors devoted two chapters to testing because this is one of the major benefits of MVC.

The final chapter describes how to integrate MVC and the traditional web forms framework into a single application. I appreciated this because so much of my work is modifying existing systems.

My recommendation is to download and read the free chapter of this book before deciding whether to invest the 50 bucks on the larger dead tree version. This will give you a better perspective on the framework and you will make the rest of the book more relevant. If your goal is simply to evaluate this framework or get exposure to it, this chapter may be sufficient.

But if your interest is piqued by Nerd Dinner, the remainder of this book is a good start in learning MVC.

Think big; act small; fail fast; learn rapidly.

These are some of the lessons from Tom and Mary Poppendieck’s book Lean Software Development – An Agile Toolkit.

The Poppendiecks take what they learned from Lean Manufacturing (many of which were originated with the pioneering work of Toyota Motor Company) and apply these lessons to software development.

They deliver advice in the form of 22 “tools” that can make a team or project more lean. Related tools are grouped together into chapters.

The authors recommend that organizations define, find and eliminate waste wherever it occurs in a process. Examples of waste in software development include defects, waiting, extra features or processes, and any non-essential activity. To assist finding waste, they recommend Value Stream Mapping - a technique in which one lists in sequences all the steps from customer request to delivery and estimates the time to completion of each step and the wait time between each step. This technique often makes bottlenecks obvious so that they can be reduced or eliminated.

Many of the tools in this book overlap. For example, iterations and feedback are listed as separate tools, but shorter iterations allow for more frequent feedback to the development team. Short iterations also expose design problems more quickly sot that the can be corrected early in the development cycle at a lower cost.

Much of the authors’ advice seems counter-intuitive. For example, they recommend against detailed planning at the start of a project and attempting to optimize every part of a multi-part project.

A popular approach among software project managers is to create in advance a detailed plan of every step in the design, development and deployment process and to estimate each step. To do so, you need to know a specific scope of everything you will build. This makes sense as a risk-reduction strategy, until you consider that environments, requirements, priorities and people often change while software is being developed. A rigid plan created up front often requires an aggressive change control process to alter that plan in any way. And for long-term projects, the changing landscape almost always forces changes to the design. Also, when users know they will only get one chance to request features, they tend to ask for far more, so scope tends to get bloated when projects are planned in this way. A better approach is to re-evaluate priorities periodically throughout the development process and keep focused on the top priority features that have not yet been implemented.

Complex project can and often should be split into a number of smaller phases or tasks. This helps to simplify the complexity. Many managers then strive to optimize each phase of the project, assuming that this goal will lead to overall optimization of the project. The Poppendiecks advise against this goal because optimizing some phases may cause a bottleneck in your overall project, thus slowing down the project as a whole. A buildup of code waiting to be tested, for example, represents waste that should be eliminated. It is best to look at the system as a whole when setting optimization goals. Optimizing each part ignores the interaction between these parts.

The book finishes with practical advice to get started making your team and process more lean.

Lean Software Development - An Agile Toolkit is a clearly-written, thoughtful book and anyone involved in software development projects can benefit from reading it.

Steve Krug’s Don’t Make Me Think is a great book, not only for what it contains, but for what it does not contain.

At a couple hundred pages (most of which are filled with large graphics), Krug is forced to be concise in order to deliver his message. There is no room for irrelevant data in so little text. Happily for the reader, he succeeds brilliantly.

“Don’t Make Me Think” is not just the title of this book - It is the single most important point Krug makes about web usability design.

Throughout the book, he emphasizes that a good user interface should be self-evident. A user seeing a web page for the first time should not have to wonder what the page is for or how to use it.

He provides many examples to illustrate his points – most from actual web sites. Krug holds up Amazon.com as an example of a site that is doing many things right, making itself intuitive for the users. It’s tough to argue this point, given Amazon’s success and enormous growth over the years.

According to Krug, most web designers make the mistake of assuming that visitors to their site will read everything on each page presented to them. The reality is that most visitors quickly scan a page, searching for anything that looks relevant to them. When they find something that seems useful and clickable, they click it. When they actually find something useful, they stop looking.

Because of this behavior, web designers should focus on simplifying their page layout and draw the reader’s eye to the most important parts of the page that support the most common activities. They should provide clear, self-evident labels for the items on their pages: there should be no confusion what each item is for and what will happen if a user clicks on it or otherwise interacts with it.

But following his design advice is not sufficient. Krug also recommends recruiting and observing testers to use your web design. Watch how they interact with the pages; note the pages that they struggle to learn; document unexpected behavior.  A designer does not always think like an end user and users often react in unexpected ways. This type of testing is a good way to learn how end users perceive and interact with your site.

Check out this book if you want a quick way to improve the usability of your web sites.

Cliff Atkinson's Beyond Bullet Points proposes a radically new approach to creating presentations based on Microsoft Power Point.

Atkinson provides a template (available for download); an outline that splits a presentation into lengths of 5, 15 and 45 minutes; and an abundance of advice on improving your presentations.

After reading the book, I discarded the template and the outline but I embraced many of his ideas.

Here is some of the book's best advice:

Allow your presentation to tell a story.
The first presentation I did after reading this book included a story about consultants Juan and Amal, who had nearly identical skills and accomplishments but received very different performance reviews. Most of my presentations are instructions on how to use software, which doesn't lend itself well to a story format. If possible, however, I try to weave a story into the presentation.

Minimize the text in your slides.
Atkinson recommends eliminating all bullet points from every slide. The only text on each slide should be a headline. I haven't gone that far, but I have drastically reduced the amount of text on each slide. When I open an existing deck, I move much of the slide text into the Notes section. This simplifies the presentation, but keeps the text with the slides when I distribute them to users. During presentation, I make the former bullet points part of my verbal presentation, rather than something the audience reads off the screen. This keeps the audience's focus on me, rather than on the screen.

Use simple graphics
A simple graphic communicates an idea visually. I have been replacing the bullet points in my slides with a headline and a single photograph that relates to the slide topic. The slides become more interesting but less distracting.

Rehearse your talk
I already knew this but the book's reinforcement helped remind me how important it is to be familiar with one's material. Nothing achieves this goal like a couple dry runs through your presentation. Ideally this should be in front of other people (to provide feedback) and in a room similar to the one in which you will be presenting; however, filming your presentation and reviewing it yourself is also very helpful.

I have not bought entirely into the Beyond Bullet Points approach. But I have internalized many of the ideas in this book and my presentations have improved as a result.

Link: Beyond Bullet Points Online

Lynnne Truss is a stickler - a stickler for proper punctuation. 

I don't know if she wanders the streets with a marker to add missing apostrophes - such as on posters for the movie Two Weeks Notice; or with white stickers to conceal extraneous punctuation - such as in a store signs that read "Boat Motor's", but I know that she is tempted to do so. I know that it pains her to see such misuse of common punctuation in public places. She agonizes each time she sees "its" and "it's" misused.

She put together "Eats, Shoots & Leaves" - a small volume designed to clarify the proper usage of punctuation in the English language and to pursuade us that it is important. 

Like Ms. Truss, I agree on the importance of punctuation, particularly in public or professional communication; but I don't always know the correct rules, so her advice is useful.

The book devotes a full chapter to the use and abuse of the apostrophe; another to the comma; a third to the dash; and so on. For each punctuation mark in question, Ms. Truss lists the proper usages of that punctuation and some common, and annoying, violations of those rules.  For example, her book lists 17 distinct uses for the comma.

It’s a difficult task because punctuation rules are sometimes vague and open to interpretation; and because the rules are often broken by respected writers; and because the rules change in a living language like English. 

But Truss does her best to clarify the vagaries and to evangelize the static, unambiguous rules. It's important because the meaning of a sentence can change dramatically, depending on the punctuation: "Extra-marital sex" does not mean the same as "Extra marital sex";

The poor punctuation of "Eats, Shoots & leaves" (the title; not the book) misrepresents the characteristics of a panda. An extraneous comma suggests that a panda employs firearms after its meal and before its exit. Correctly punctuated ("Eats shoots and leaves"), the phrase describes a panda's favorite meal.

Most of Ms. Truss's advice does not sound like a textbook. Regarding comma usage, for example, she dictates the rule: "Don't use commas like a stupid person". What she means is that one should step back and read a sentence to verify that the punctuation conveys the correct meaning. 
For example, the sentence
"Leonora walked on her head, a little higher than usual."
is grammatically correct, but probably not what the author intended.

Despite her passion for the topic, her style is light and engaging. I laughed out loud several times while reading this short volume. She parenthetically refers to Gertrude Stein as a "strange woman" (presumably because she disagrees with nearly every opinion Ms. Stein holds on punctuation); and she once described a long, over-punctuated sentence as exhaustedly slipping into a comma.

I really enjoyed this book and will keep it on my bookshelf beside Strunk and White's excellent The Elements of Style because it is concise, accessible and extremely useful.

Edward Tufte has spent a lifetime turning data into pictures and studying the best way to do so.

In his first (self-published) book The Visual Display of Quantitative Information, he describes what makes an excellent graph or map. 

Not all data sets are good candidates for charts.  For small data sets with exact values, Tufte recommends using tables.  However to compare values or present many pieces of data simultaneously, a graph is far superior.  Graphs, Tufte asserts, are most useful when showing complex data and displaying trends or observations that are not immediately obvious when the data is displayed in tabular form.  An excellent graph is one that is clear, precise and efficient - that is it "gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space."

Tufte provides some advice to accomplish this graphical excellence.  He introduces the concept of "Data-Ink" ratio.  This is the amount of information conveyed by a chart, relative to the amount of ink required to print that chart.  Generally, a graph can be improved by increasing its Data-Ink Ratio.  This can be accomplished by erasing non-data ink, such as unnecessary gridlines and labels; by erasing redundant data; and by labeling data directly, rather than forcing users to look up information in a legend.

Related to the Data-Ink ratio is his push for high data density - graphics that have maximum data per page, maximum data per square inch, and maximum data per amount of ink used.  As long as a graphic does not appear confusing, cluttered or overwhelming, you should pack as much information as you can into it.

Tufte warns against "chartjunk", his term for irrelevant text, lines, pictures or other decorations that contain no actual information.  This is ink that can be erased from a chart without reducing the amount of information in the chart.  Many graphs contain pictures, 3D effects and colors that don’t relate to the data.  Rather than enhancing the user’s understanding of the data, this “junk” distracts the user’s attention from the data, making the graph harder to understand.  Erasing chartjunk increases the Data-Ink ratio, which should be the goal of every designer of data graphics.

I appreciate that the book provides numerous examples of both the right way and the wrong way to represent data visually and that most of these examples came from real-world publication.  Tufte pulls no punches in his criticism of those who do things the wrong way.  In describing one graph published in American Education magazine - a confusing 3D graph that shows only 5 pieces of data and uses 5 different colors that in no way relate to that data - he writes "This may well be the worst graphic ever to find its way into print."

This is an excellent book for anyone who needs to present data to an audience.  Business analysts, managers and software developers can all increase their effectiveness by implementing Tufte’s ideas.

Links:
EdwardTufte.com
This book on Amazon