Customer Reviews

Software Creativity 2.0

5 star:		(6)
4 star:		(2)
3 star:		(2)
2 star:		(2)
1 star:		(0)

 

 

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.

This is a loosely-knit collection of essays that range from the brilliant and thought-provoking to the mundane and pointless.

Glass sheds useful light on the conflict between agile methods and those which demand control - Greeks vs. Romans, in one analogy. Is more process better, or not? This is a struggle that many companies are dealing with, with proponents on both sides. I can relate well to this having worked in both types of organizations. As a longtime software practitioner, Glass naturally comes down firmly on one side of this issue, but advocating a path that is practical and useful. And I loved his question "Is programming fun?" because this is something everyone seems to have lost sight of.

A few things that I really didn't like:
* One point where the author suddenly launched into gratuitous political comments that were irrelevant to the point of the article. It's always an author's privilege to do this, but the injection of politics (or religion) into subjects like this where they have no place immediately cause me to wonder if the whole message is somehow tainted by the author's need to make more points like this.
* At another point the author recoils in horror (calling it "strange and jarring") that Watts Humphrey would cite IBM as a example of a company with strong innovation. Humphrey's book on innovation was published in 1987, when IBM was still the undisputed technology leader as it had been for 30 years, responsible for most major hardware and software innovations of that period. Although IBM today is a shadow of its former self in that regard, it still produces more patents than any other company worldwide. For Mr. Glass to dismiss IBM demonstrates either bias or shallowness of understanding on his part - perhaps his background in aerospace and academia confined him to a different part of the planet than the vast majority of actual software practitioners lived on. If so, that calls much of his opinion into question.

Despite this, and despite the varying quality of the essays, this book is still a worthwhile read, primarily for the various insights and perspectives on the topics the author does actually understand well. However, this book is NOT on the level of Mythical Man Month, regardless of what Mr. McConnell thinks.

It's a quick, but heavy ready. However, this is a great little peak into the psychologies involved in software. It's something I recommend all developers, managers, etc. to read that work in the tech industry.

You may not walk away with any new ideas, but you'll definitely have a better understanding of what's running through people's minds (and that applies for coders, architects and even managers). The topics covered on business vs. academia are priceless in terms of examining the current state of affairs in the tech world.

Pick it up and give it a shot.

If you're writing any papers/essays on topics related to tech, this would also provide a great reference and has many entertaining and potent quotes.

The Problem mainly with this book is that it is not aligned with the typical Software Engineer mentality, many software Engineers turn to books looking for definite answers to questions hovering in their minds..the fact is this book barely answers any questions. It is the nature of the engineer to look for binary answers. That being said is it a probelm with the book itself or the targeted audience?

To some, a good book will actually answer some of their questions, like the how to books or the academic ones, if you agree then Software Creativity 2.0 is not a good book, and you are the typical "engineer" I was talking about.

A great book will answer your questions with more questions, widening your perspective leaving the ultimate answer for you. The subjects turned in the book are very controversial, and no one, except fools, can claim to hold the correct answer for all contexts and situations. Most of the time the answer for these questions is context dependant, that is where Dr. Glass shines at his best, explaining the contexts of each possible answer for each question and the possible trade-offs, for many this is not a satisying answer, for me it's a good enough answer, and as good as it gets!

Golden rules don't exist in real life, they only exist in the minds of their holders. The book is based on the idea that if you want adopt a rule learn more about the exceptions of that rule than the rule itself, the "No silver Bullet" notion. Glass intentinally doesn't give answers, and he never actually meant to give answers in this book, read the last essay of the book when he intentially picks a "yes" answer for a multiple choice question. He only wanted to stir a conversation, a mental conversation between you and the book, you and yourself, you and and other programmers, even you and other non IT people, and hell yeah it worked for me, I have been thinking so hard since I started reading this book, and harder after I finished it.

All in all One of the best books I ever read.

IF you are the typical binary Engineer this book is not for you, you are better off reading academic or SEI articles which claim to hold the truth of it all.

It is sad that the body of engineering shifted from creative heurisitc context driven world to a world looking for silver bullers and golden rules. The reviewers comments, selling figures, and rating of this book prove my point. No wonder we why soceity looks down at us, and found the name "book smart" for us.

That being said, the answer for the question in the first paragraph is a BIG "YES".

Robert Glass' essays are short, easy to read, and almost always annoying. This is a Good Thing. Software Development these days marches forward in PMO lock-step, or dances excitedly to the Agile tune, but few stop to ask questions. Like, "How much of software development is creative, or intellectual?" Or, "Is it fun anymore, and how does that matter?" I say "annoying" because the short essays (some under 5 pages, wide-margin) are too short, and often sound argumentative or know-it-all as you start reading. But that's what Glass wants -- readers who are awake. Who say, "Wait a minute! That's not right. Or that's not what I think." But then on second thought, "maybe he's got a point".

I'm reminded of an unusual lecture I heard at the The 12th Annual
International Deming Research Seminar (Fordham U., New York, Feb. 2006): "THE CHALLENGE OF BOREDOM: Problems in Defining, Measuring, and Explaining the Causes", presented by one Josh Kross. The lecture wasn't boring, but I did wonder a little at this MBA student telling us earnestly about boredom, and how hard it is to pin down a useful definition. Now I understand: we need the opposite in software development. Software managers would do well to stop and think about what "boredom" is, to avoid it for their developers, and for themselves. Only interesting, fun work will both encourage discipline, and produce devotion, productivity, and high quality. Glass is talking about the same kinds of things as he returns a second time to his topic, in Software Creativity 2.0. Annoyance has never been so well worth it.

-==Pro's==-
-Author cites his sources.

-The author presents some new ideas, that seem to be fresh.

-The author has a good sense of humor, and in sections of the book his writing style is enjoyable.

-==Con's==-
-This book at times seems as if it goes out of its way to stir people up.

-The title and description of the book led me to believe it applied to my area of interest, however it did not.

-Some of the things I read, I just plain disagree with.

-The author gives advice based on theory, and uses anecdotes rather than facts.

-==summary==-
For the most part, the reasons I do not like this book are personal. I am a solo programmer. I work alone on small personal projects as a hobby. It seems as if there are not many programming methodologies that apply to me in this position. I had hoped that this book would have some tidbits that would prove useful for me. Early on, the book states explicitly that it is not intended to be useful for the solo programmer, but does give some recommendations on what a solo programmer could read. After reading through the first half of the book I found myself very disappointed.

The book had some disturbing views on the relation between Mathematics and Computer Science. It reads something like "There are word processors and simulators and games and software tools of various kinds, such as compilers, all of which do virtually no mathematics whatsoever.". This is a quote. I believe in the section of the book I got this from, the author is making a case for why math should not be taught as heavily (if at all) in CS courses. There might be no math in *some* games and simulators, but if there is, I have not seen it.

The author also has a strange view that I do not agree with, about the quality of a solution to complex problems. The idea is that once you have a solution that is "good enough", then its done. As long as you can call it "supportable" meaning, you can make a case for why it should not be tossed, then it is a done/acceptable solution. I do NOT agree with this. Perhaps these are the things M$ say when writing their OS, and why it is slower each new version >). I understand that one cannot optimize to infinity, but this is where the reason I'm reading the book comes in. I am programming as a hobby, so I have the luxury of spending however long it takes to find a solution that makes me happy. I do not have to settle for the first "supportable" solution.

If I had to describe this book in one word, it would be flaky.

I picked up this book based on Steve McConnell's recommendation in Code Complete. Things were slow through the first chapter, but it only got better the further I read. This is another fantastic book by Robert Glass.

Steve McConnell's original review here on Amazon does an excellent job at summing this book up.

One point not brought up by other reviewers: I think the typesetting in this book is really, really poor.

The typefaces look "cool," but for me, they obscure the text and make me tired. Also I find the font size is too large for a comfortable read. Inner margins are way too small. I am confused how it could be so messed up.

I have tons of books I want to read, unfortunately I will put this one to the end of my list, as the typesetting just doesn't make for an enjoyable reading experience.

Sorry that I can't review the content (yet), I really would have preferred that.