Software Craftsmanship: The New Imperative

Book Review-Software Craftsmanship: The New Imperative

I struggle to find the right way to express how to make software development right.  I can’t say that I subscribe to every idea that is put forth by Software Engineering.  The Software Engineering Institute does drive software development forward.  However, having had the opportunity to listen to a few of the speakers that work for the SEI, I can’t say that I feel like they’re in touch with reality.

The appealing thing about this book, Software Craftsmanship- the New Imperative, is the opportunity to take a different perspective towards software development.  I’ve always felt in some ways that building software was about getting a feel for the users, the technology and making them come together.  The idea that you don’t build software you craft it is certainly appealing.

The whole book puts forth the idea that we think about software wrong.  We take the few examples of large projects and expect that the experiences gained there will apply to every software project.  There have been numerous observations that the software development practices that we know, from these observations, lead to better software are routinely ignored or not followed.  Although there are many reasons for this, the reality is that we don’t do what we are taught to do.

The other end of the spectrum is the apprenticeship model that’s practiced in many other professions either from a formal structure or informally. Most trade professions have some sort of a process from taking apprentices and making them into professionals.  This is an approach that the author proposes we should be doing with Software Development.

In my own experience, I can say that both are needed – and the idea of software as a craft is widely under discussed in professional articles and books.  Despite this it’s the primary way that I teach, and learn, about software development and how to make it better.  As a coach and mentor I train developers to remember to watch error handling, to test, to think about boundary conditions, to care about the resulting code, and all of the things that make up good software.

They learn not through the one time reading and single verbalization of these ideas but through the continual reinforcement of the ideas and the continued application of the ideas to their work.

I learn through work with my colleagues.  They teach me their approach and I teach them mine.  Whether I alter my approach or they alter their approaches, we’re both better for the exchange.

The book is somewhat repetitive in places and over the top in others, however, it’s a good read if you can put aside the details and focus on the core message and evaluating it against the way that you do software development today.

Dynamics of Software Development

Book Review-Dynamics of Software Development

More than 10 years ago Jim McCarthy wrote the first edition of Dynamics of Software Development.  At that time it was a great book.  It helped identify specific behavior patterns that software development teams fall into.  Perhaps the most familiar behavior pattern is flipping the “Bozo bit” – in other words writing someone off as not a valuable member on the team.  Small nuggets of insight like this one are woven together into a tapestry of the behaviors you don’t want to see in your team.

But that’s where the 1995 edition of the book stopped.  You knew what you didn’t want to see and had sign posts to alert you that they were coming.  However, there was very little in the way of support for creating the right kind of behaviors and exterminating those behaviors that you had been warned about.

The 2006 edition in addition to the 1995 content has content designed to support your transition from a team where these behavior patterns are the norm to one where you’re looking for the rare case where there’s some bad patterns emerging.

The “Core System” as Jim and Michele McCarthy describe it is a set of patterns, antipatterns, and “Core Protocols.”  The “Core Protocols” are as set of specific behaviors which support the proper working of a software development team and inhibit the growth of some of the other patterns that are not so favorable.

Dynamics is a book that every development leader should read.  More than that — it is a book that should be used as content for team meetings.  By dissecting one of the 57 rules included in the book you can generate a few minutes worth of discussion on a single, important software development project so that you can move the team forward, one sound byte at a time.

Agile Software Development: The Cooperative Game

Book Review-Agile Software Development

With all of the books with “Agile” in their title today why would anyone want to single out Agile Software Development in particular?  My reason was the author Alistair Cockburn.  Alistair has been a part of the agile movement being both an original signatory on the Agile Manifesto and the proponent of the Crystal Clear methodology.  In other words, the resume isn’t bad.

Agile Software Development is both interesting and unique because it’s unlike other books about agile development that you might read.  First, it’s in some ways more of an extension of Peopleware and The Psychology of Computer Programming.  It talks about why developers behave the way they do without condemnation or excuse.  It speaks about the way things are and what you can do to get better results.  Alistair’s understanding of the dynamics of communication can help you construct solutions that allow your team to communicate more effectively.  Either its “rearranging the furniture” or “vandalizing the walls” there is an understanding into the psychology of how things work – and why they work that can be effective whether you’re deciding to adopt an agile methodology or not.  (“rearranging the furniture” and “vandalizing the walls” aren’t his terms – their my colorful summaries of things like evaluating communications like the dispersion of heat or a gas and a concept that Alistair refers to as information radiators.)

On the topic of methodology there’s a lot to be had as well.  I’m preparing for a web cast titled Defining Your Own Software Development Methodology.  In that web cast we’ll be talking about how to create – or more appropriately tailor – a methodology for your organization.  In addition to having some great “sound bites” for that discussion, the model that Alistair uses to talk about methodology creation has influenced some of the web cast material.  Coverage of the characteristics of a methodology, the way to approach usage, and the impact of lighter and heavier methodologies have all been positively impacted.

I’ve always respected the simplicity and usefulness of Alistair’s breakdown of projects based on size and criticality.  The breakdown of criticality into Loss of comfort (C), loss of discretionary monies (D), loss of essential monies (E), and loss of life (L) has been quoted many places.  The reason I appreciate it so much is that it simplifies the task of speaking of the size and characteristics of a software development effort into something that can be quickly understood by all.

As both a word of caution and one of praise, Agile Software Development doesn’t take a formulaic approach to delivering the content.  Instead it gives you all of the components you need to understand how things work and leaves the exercise of making it work to you.  While I find this approach very appealing because I am looking for different views and perspectives which I can add to my toolbox, it may be frustrating for readers who want someone to tell them what “the answer is.”

I leave you with one of my favorite sound bites from the book (p71):

“Although heroes who work overtime may be needed to save poorly run projects, there is a much more interesting phenomenon to observe: ordinary people doing their work with a sense of pride and community and in doing that work noticing something wrong, passing information to someone who can fix the problem, or stepping out of their job descriptions to handle it themselves.  This is an indicator of a community in action, not an indicator of a poor development process.”

Agile Software Development with Scrum

Book Review-Agile Software Development with Scrum

If you regularly read this blog then you know that I’ve been doing a lot of reading and reviewing of agile methodology books. (Agile & Iterative Development: A Manager’s Guide, Balancing Agility and Discipline: A Guide for the Perplexed, etc.)  It’s a curiosity of mine both in terms of looking for things that can help with current methodologies and how one might do the best implementation of an agile method in a project.  I’ve also been reviewing more traditional software development titles to see how they might be useful in making projects more successful (The Security Development Lifecycle, The Psychology of Computer Programming, Peopleware, The Rational Unified Process Made Easy: A Practitioner’s guide to RUP, etc.)

One of the challenges is finding a book that talks about real world experience with agile methodologies.  Agile Software Development with Scrum is that book.  While Ken Schwaber and Mike Beedle are careful to include the fundamental psychology that makes Scrum work, they also share many personal experiences with how projects have succeeded or failed – and what factored into those successes and failures.

While the book won’t make you a good Scrum Master right out of the gate, it does go farther than other books in explaining the psychological underpinnings of Scrum ideas so that you can adapt the methods to suit your needs – most Agile proponents and books advocate a “no changes” sort of policy.  While this book doesn’t directly encourage making changes it takes a much softer line on the issue than previous agile development books.

Whether you’re looking for the practical details of how to implement scrum or the background to understand why scrum works, you’ll find an answer in Agile Software Development with Scrum

Blink: The Power of Thinking without Thinking

Book Review-Blink

Back in January I read (and reviewed) Malcom Gladwell’s book The Tipping Point.   I liked it so much that Malcolm’s next book, Blink, quickly made my reading list.  I don’t read many books that don’t have some sort of technology tie-in so Blink was a good change of pace.

The basic overview of Blink is a walkthrough of how we make snap decisions (quick decisions), why they’re mostly right, how that works, and how to make better use of the unconscious thinking that goes into  those quick decisions.

The subtitle “The power of thinking without thinking” is appropriate because it exposes how our unconscious mind is always thinking about the situations around us even when our conscious mind is not.

It’s a great exploration of the topic – particularly since I’m fascinated by the change that takes place from the first time you do it vs. when you’re proficient at it.  Flying for instance.  The first time I flew a plane it was way too much information.  I couldn’t do things fast enough.  I couldn’t evaluate all the variables faster than the plane was flying.  Now I don’t even consciously think about the variables involved in landing a plane.

If you’re interested in how you make snap decisions, why they’re right more often than not, and what to do about the situations where you’re not right, Blink is a book you should read.

The Security Development Lifecycle

Book Review-The Security Development Lifecycle

The need for a higher level of attention to security in applications is something that we must unfortunately deal with.  Finding a set of developers with an intrinsic knowledge of security is much like looking for a taxi cab when it’s raining.  You know they exist but you don’t know where to find them.  That’s why you need a framework for creating the right kinds of security awareness, knowledge, and discipline.

If you wanted to find an example of an organization who clearly exemplified the problem a few years ago and one which had made great advancements in the area of security, the best example may be Microsoft.  Microsoft was once the favorite target for hackers and the media, Microsoft is making progress towards becoming the most secure products available.

The Security Development Lifecycle is a look at how Microsoft has made this transformation with specific guidance on what to do, how to do it, and what the impacts are.  Asides within the text highlight items that worked well for Microsoft but may not work well for your organization – and techniques that were expected to be greatly helpful but were not.

The book is amazingly insightful in terms of its view of the problem.  There’s no bravado about having all the answers nor is there any concrete feel to these are the only answers.  It’s a good discussion about what has worked in practice.  The authors clearly believe that new types of security vulnerabilities raise their heads as new attempts are taken by security researchers to break the software that we produce.

While the details of individual lines of code are not thoroughly covered, the core concepts are explained well and with enough detail that you can develop your own coding practices which are inline with the overall security strategy.

This is a must read for architects and development team leaders who are concerned with the security of their code.  It’s a great read for those developers who have an interest in leading a development team at some point.

Web Hacker Boot Camp

Book Review-Web Hacker Boot Camp

“What evil things lurk inside the hearts and minds of men… “

When I was still in high school – many moons ago – I remember a programming competition. We were supposed to create a program that calculated the length of a line in a triangle (or some such trivial problem). To test your application once you said it was done, the judges would often enter a negative number for the length of a line. On a whim we had put a trap in for that particular condition while building the program. It was this test that helped us complete the challenge.

Putting testing into our code today for bad values seems commonplace. We test for values out of range and have validation controls and all sorts of things that lead us toward developing more robust solutions. However, despite all of our advances in the areas of validating user input, we as an industry still struggle with security issues in our applications.

While the news may be focused on the next new exploit of Windows – because that has mass appeal –  we are still finding that our applications have their own flaws in them that can be exploited just as easily as someone exploiting a flaw in Windows. Actually, much of the time the mistakes in our applications are much more trivial to reveal.

Web Hacker Boot Camp is a journey through the mind of a hacker. It reveals how hackers do their job and what their techniques are. It stops short of telling you precisely what to do to make your application secure, but it certainly provides you with the information you need to think about to make the application secure.

There’s good content in this book if you’re interested in how to fortify your application against attack. The only downside is that you’ll have to look past some editing and layout issues to get the information out of the book.

If you want to discover how you could lose control of your web servers because of flaws in your application code, Web Hacker Boot Camp is definitely a book to get.

SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Book Review-SharePoint 2003 Advanced Concepts: Site Definitions, Custom Templates, and Global Customizations

Whenever a new SharePoint book comes out I’m very hopeful. There is so much to learn about SharePoint. Some of these things are strategic and cultural. Others are the inane details that allow you to make SharePoint do what you want it to do.
I quickly put this book into the details category with the highly specific and technical title. I was not surprised in this way. It drops down right into the details, right away. No stopping to smell roses, or fluffy introduction chapters – “just the facts, ma’am.”
Unfortunately, my read of the book led me to wonder whether it was providing extra value or not. Primarily, I was thinking about these free resources that have a similar level of coverage:

If you prefer a book that provides a lot of information in one place, rather than taking the time to gather it for free, this could be the right book for you.

This isn’t a book that I will generally recommend, but it does a reasonable job of covering the material, even if it does sometimes make leaps of understanding.
The Psychology of Computer Programming

Book Review-The Psychology of Computer Programming

One of the more interesting questions that I get is how to get an organization to adopt agile methods. Sometimes folks frame it in terms of a problem: “I’m trying to get my organization to buy off on agile development, but they’re not convinced.” I believe that the book The Psychology of Computer Programming can really help with making agile development more powerful. Let me explain.
One of the things that I’ve noticed with most of the agile books, articles, postings, and so on, is that they describe WHAT to do and HOW to do it. However, they are noticeably missing the WHY it works. They’ll argue that WHY to do it is that you experience more productivity, efficiency, quality, etc.; however, they rarely attempt to explain WHY those benefits occur.
So how can a book that was written 25 years ago explain how agile works? The answer is simple. Agile works because it capitalizes on the psychology of programming – even if it only capitalizes on it by accident. Penicillin was created by accident, remember. Some of the core reasons why agile practices work are explored with experiments in The Psychology of Computer Programming.
By now you should be asking, “Okay, so how could I use it to help me sell agile to my organization?” The answer has to do with some of the antiquated material in the book and the way that they may seem nostalgic to the managers who are leading the technology department.
The book was originally published in 1971, so its references are, to say the least, a bit dated. The language examples are FORTRAN and PL/1. The most prevalent system mentioned is OS/360. There are references to punched cards and computer rooms. Terminals are just beginning to gain favor. However, despite the quite noticeable and sometimes distracting antiquated references, the core messages about how programmers (developers) work with one another and with the computer are still clear.
Frankly, the references to older systems make the book more credible than the respected agile books of today. Senior technical managers often will remember these systems with a sense of loss that they can no longer develop code. (Everyone’s inner geek suffers when it’s not allowed to grow.) Because of this connection, the more formalized study methods and the slightly academic feel of the writing makes it a book that is believable to anyone who grew up through the technical ranks.
So how do you use this? First, read a copy of The Psychology of Computer Programming, plowing through some of the parts where it seems like there may be little to offer in terms of today’s agile methods. Highlight the sentences and paragraphs that align to today’s agile practices. Then hand it over to the manager who’s not convinced that agile is the way to go and ask him to read it.
You know that they aren’t likely to read it, but they may flip through and notice your highlighting. You’ve got them hooked. If they read around the highlighted passages they’ll find that comfortable nostalgia and, hopefully, settle into trusting the book.
From there, it’s just a matter of hinting that you should try some of the ideas outlined in the book – that just happen to align with one of the agile methods you’re looking at starting.
I have no idea whether the founders of the agile methods that folks are reading today read The Psychology of Computer Programming, but whether they did or not, there are certainly some interesting correlations.
Peopleware: Productive Projects and Teams

Book Review-Peopleware: Productive Projects and Teams, 2ed

I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams.  It wasn’t because the material wasn’t good — it definitely is.  It’s not because I felt squeamish about the title — I didn’t.  However, I did feel like I should have somehow managed to have read it before now.  With the original edition written in 1987 and the 2nd edition written in 1999 — I should have read it before now.  Alas, I hadn’t.

Peopleware is, as the title suggests, about people.  It’s about how people and software development fit together.  It’s not another methodology, it’s not a set of programming tips.  It is, however, some interesting insight on how people work, don’t work, and work together.  It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.

I collected a few quotes that I believe highlight the value of the book:

  • “The major problems of our work are not so much technological as sociological in nature” (p4)
  • “The statistics about reading are particularly discouraging.  The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.” (p12) [Ouch]
  • “People under time pressure don’t work better; they just work faster.” (p18)
  • “Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code.” (p21)
  • “People just don’t work effectively when they’re locked into a no-win situation” (p28)
  • “The manager’s function is not to make people work, but to make it possible for people to work” (p34)
  • “People can keep track of only so many human interactions” (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]

The book read, to me, as the background information one needs to understand why agile methodologies work.  It’s sort of like reading a book about the internal combustion engine when you drive a car to work every day.  You don’t have to know how the car runs, but when you break down on the side of the road it comes in really handy.

If you’ve not managed to make it through this classic work and you work with others as a manager or as a team member — you should.