There's a fundamental conflict in the software world, sometimes taking on the attributes of a war. On one side, managers search for ways to impose more discipline and control on software builders, and researchers advocate and sometimes seek to mandate formal methods for the same purpose. On the other side, software builders quietly continue to build software pretty much the way they always have, with freewheeling methods and creative solutions. "Breakthrough" methods come, linger awhile, and go away, having made little impact on our ability to build software
Review By: Garry Archer 12/08/2008The content in this book should last for some time, as it does not have a shelf life like most computer books. The content deals with the decision-making processes versus methods that mature and will eventually be replaced. Software programs come and go as the needs to enhance or improve them arise, but the thought processes behind their development and creation are human born and bred.
I didn't find the book immediately useful in any technical way. Rather, I treat it as an interesting read about the practical and not-so-practical approaches to the role of creativity in software engineering and programming. Perhaps it is even a historical piece of reference material worth the read for all those willing to get their feet wet in the software industry.
Although author Robert Glass lost me at times, he was able do a summation at every step of the way which put my thought process back on track. With all his wealth of knowledge and experience, it must be very hard to condense years and volumes of information into a 400-page novel. I say "novel" as it tends to read more like an adventure novel, not a technical manual. Regardless, Robert gets his points across well and shows all points of view from the heuristic to the formal. His use of references is impressive and is more than adequate to back up his ideas and visions.
The expert might read this book as a historical tracing for the creative process that has evolved from the beginning of the technology. Novices, on the other hand, may be overwhelmed when first reading the book, but would still benefit from reading it, especially as the novice’s craft matures over time. I would therefore say it is aimed more at the expert, yet I will recommend this book to my peers.
I had a lot of fun reading this book as I found it to be spot on with many ideas and thoughts that I have had or experienced over the years when programming. I truly like the ad-hoc/heuristic approached Robert mentions in this book. Creativity, in my opinion, can only be learned to a small degree. As Robert mentions in his book, some people feel you either have creative skills or you don't. As necessity is the mother of invention, creativity is the spark that lights the fire to that end.
Review By: Michael Kahn 12/08/2008Software Conflict 2.0 is a collection of easy-reading essays on a variety of software topics. The essays, for the most part, are written from a philosophical viewpoint. Each essay takes between five to ten minutes to read. Although the original edition was written well before people were reading blogs, the essays do have a blog sort of feel to them.
The essays are grouped into sections organized by topics such as methodologies, management, and software research, to name a few. Throughout the book, there are new essays presented as "retrospectives." These retrospective essays offer comments from today's perspective on the timeliness (or datedness) of the other essays in the section.
The essays do not focus on specifics, which has helped them stand the test of time. You won't find any discussions of how to add a math coprocessor to a 386 machine, or whatever other hot topics were happening in 1990, when the first edition of this book was released. Instead, the essays focus on paradigms, trends, and some platitudes which are thrown in for good measure. In an essay on the topic of choosing a high level language or a low level language, the author basically says that where possible, use a high level language, but when efficiency is the prime goal, a low level language may be best. The book provides many such "insights" that many in the software business would consider common sense knowledge and would find nothing really new or earth-shattering in those conclusions.
Another example can be found in the essay on the pros and cons of software prototyping. The author presents various advantages of prototyping as well as concerns such as the danger that a substandard prototype will become the "real" version. The essay posing the question: "How do you manage prototyping?" and basically provides the answer that "we're still not sure how to do it."
If you are looking for specific advice on a topic, then this is not the book for you. However, if you are interested in a collection of well-written, thought-provoking essays of the science, psychology, and philosophy of software, then you will find this book enjoyable.