Software Creativity 2.0 [Kindle Edition]

Creativity is mentioned frequently in software discussions, usually with only a bare awareness of the factors that contribute to true creativity and usually with only the most superficial understanding of the role creativity should play in software development.

These common references to creativity might be misguided, but they speak to an important truth: creativity is a topic of central importance to software development, and this seminal book provides a vivid explanation of how and why.

Most of the book is structured as a study in contrasts: discipline vs. flexibility, quantitative vs. qualitative, process vs. product, theory vs. practice, and so on. This is not just a tidy, contrived organizational structure. These contrasts define longstanding, conflicts in software development -- "essential tensions" if you will -- that are not likely to disappear anytime soon. Indeed, the intellectual energy generated by these "essential tensions" prod the explorations and spark the debates that, over time, keep the software industry moving forward. Glass explores these contrasting & conflicting positions with a rare appreciation for the value that both sides contribute to the software field.

Glass's writing style is light which sometimes has the effect of understating the importance of his subject matter. It's easy to breeze through the chapters, viewing the content as entertaining but not particular substantitive. It's only later -- when you see an agile zealot debating a process bigot, or when you a see an academically-authored article bemoaning the poor state of real-world practices -- that you think "none of these people seem to understand what the real issues are," and you realize that you've gained some uncommonly powerful insights from this book.

No book is perfect. The most conspicuous issue is that the book draws on Glass's writings over the past 40 years, in some cases with few or no updates. While I wish the updates had been more pervasive, many of these "dated" essays address issues that will resonate with today's readers, which really just underscores Glass's contention that the issues are timeless, that is, fundamental to the nature of software development itself.

Glass takes a very personal approach to the writing, and some readers might find his approach too self-aware. Topic coverage is uneven in places, and readers will find themselves wishing he had gone into more depth in some places and less depth in others.

When all is said and done, these limitations do not reduce the overall value of the critically important discussion presented in this book.

The first edition of Software Creativity, published in 1995, has long hovered near the top of my personal Top 10 list. Software Creativity 2.0 is more polished, more readable, and benefits from Glass being 10 years older and wiser. Software Creativity speaks to issues as core to software development as Peopleware or the Mythical Man-Month, and does so just as articulately.

Robert Glass has given the software world many gifts during his 50 year career in software development. This book stands above his other contributions as his magnum opus. I cannot recommend it highly enough.

Too often pragmatic concepts in software fall victim to zealot practitioners whose ideology includes panacean promises of one-click programming and ideas that good process guarantees a good product regardless of personnel. Too many people still promote their ideas and methodologies as cure-alls. These people treat software as a franchise with a factory-line assembly and replaceable parts. It is anathema for many to think of software as a creative endeavor. However, this idea that software development lives and breathes with creativity is what software curmudgeon Robert Glass takes on in his sagacious book on software. This book is a newer version of his original 1995 "Software Creativity" which has been unavailable (cheaply) for many years.

This book is divided into four parts. The first part (and I feel the most important of the book) is the exploration of software creativity. Here he takes on nine dichotomous subjects (discipline vs. flexibility, formal methods vs. heuristics, optimizing vs. satisficing, quantitative vs. qualitative, process vs. product, intellectual vs. clerical, theory vs. practice and industry vs. academe, fun vs. serious) and explores the advocates on both sides and tries to find definitive answers (or at least raise more questions).

What I found fascinating about several of these chapters like quantitative vs. qualitative and industry vs. academe is that they can apply to many different industries and not just software. How many times has quantitative reasoning been used in business only to fail miserably in the hands of MBAs? How can academe differ so much from practice (like getting your Juris Doctorate compared to really practicing law)? These chapters are a plethora of interesting ideas that many of these chapters can be discussed at length (imagine the length of the review if we tried) and one fault (that has already been mentioned by several reviewers) is that some of the topics need more discussion.

The second part deals with making creativity happen. I feel this is such a difficult thing to do in large organizations since it involves a paradigm shift in thinking, but it is a must for small companies. The third part deals with creativity in other fields and the fourth is the conclusion. And to give away the ending his thoughts can be summed up as "...is that our one-size-fits-all approach is wrong. No, it is worse than that. It is WRONG!" The one question that remains is how do you change a practitioner's mind that already has all the answers?

I never read the original book; I did not get into Glass's writing until I received as a gift Glass's Facts and Fallacies of Software Engineering and became enthralled with his pragmatic point of view. That laconic work got me interested in his writings and when d.* brought out this book I bought it immediately. Software Creativity is not as well known as Frederick Brook Jr's masterpiece "Mythical Man Month" or Edward Yourdon's "Death March" (and many others) but it is such a great read that anyone involved in software can benefit from this book. I am biased though. After years of "software development" I have found it to be a very challenging and rewarding endeavor that does benefit from structured creativity. Apparently Robert Glass feels this way too.

Can I give it 10 stars?

I could write volumes about this book, but perhaps the most important thing is that it allowed me to rid myself of guilt about not following rigid software process. In the back of my mind, I always knew that software process as I've learned it is impractical and in many cases infeasible. However, it was taught in school as if it's (obviously) the only way, and therefore I had a lingering guilt about not being able to follow it precisely.

Glass speaks with a thundering voice from the practitioner's perspective exactly what is wrong with rigid software process and creativity-stifling management styles. He also explains the evolution of software process, and makes it very clear that we're no where near a satisfactory solution.

Why should you care what Glass has to say? For one, he's been in the software industry longer than most current software developers have been alive. He's also spent many years in academia, and has excellent insights on what's wrong with that side of the fence as well. But, above all, because what he says is true. Every once in a rare while you read something that rings so loudly that it can be nothing else but true. If you're a frustrated software developer, this is that book.

I applaud Glass for presenting such an honest discussion of the role of creativity in software process and management. I have no doubt he's made a few enemies along the way, but the discipline is certainly the better for it.

In short, if you're in the software field, and care at all about the future of the discipline, go out and get a copy of this book and read it cover to cover. Your career and the discipline as a whole will be the better for it.