|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
Software Engineering: A study akin to numerology and astrology,
but lacking the precision of the former and the success of the latter.
Software engineering (SE) has probably largest concentration of snake oil salesmen. Even object-oriented design cannot compete with SE ;-). Such "dynamic" figures as Yourdon, Ben Shneiderman and partially Gerard Weinberg (at least the latter authored one interesting book and a couple of decent tutorials on PL/1), could probably compete with any woman fashion designer :-). These guys are really can change their own position twice a week, as they sense that something new becomes fashionable.
I am not that impressed with current OO and software patterns fads, and openly prefer tried and true approaches. I still think that the famous Brooks The mythical man-month book is more applicable to current situation that many modern books and that there is no silver bullet in software engineering.
I think writing a good program is somewhat similar to writing. Most writers will rewrite a paper or book several times. Rewriting programs is more difficult, but very beneficial. It make sense always consider the current version of the code a draft that can be substantially improved and some hidden simplification revealed. Sometimes you can be wrong so good configuration management system is needed so that going back was always both easy and possible. Too often people try to debug their fundamentally flawed "first draft", when it would have been much simpler and faster to rewrite it based on problems discovered when try to debug it and the problem is better understood. That way, when you're done, you may get easy-to-understand, simple program, instead of a mess that "seems to work okay" (only as correct as your testing).
Refactoring (see Refactoring: Improving the Design of Existing Code) can be a useful simplification technique. See Slashdot Book Reviews Refactoring Improving the Design of Existing Code.
You can use Honor System to make a contribution, supporting this site
Unified junk??? Very questionable approach. Solders of the software army might just be disgruntled enough to pull management legs and chose not to reveal probalems with the architecture. IMHO as soon as a good software developer understand that software manager is a jerk who wants to impose his will independently of the merits of his approach this managers with their idiotic UMLs and methodologies are doomed.
Valuable Reductionist Essentials, March 13, 2001
Royce's text provides a lucid, straightforward explanation from an elitist management perspective of how UML can be applied in various business and technical settings. The perspective offered brilliantly summarizes how a technical management methodology can be used to exclude software engineers from asserting control over the production processes in which they participate. The premise set down is that managers must impose rationality in software development organizations only from above and that software developers are basically their own worst enemies. "Rationalized" processes implemented from the top enable managers to bring control and conformity to software engineering environments and ultimately reduce software developers to a depersonalized, production-line condition that has the result of forcing them to increase efficiency and the reliability of their products while at the same time shortening the time to delivery.
Reviewer: "left_hand" (Boulder, CO United States) - See all my reviews
The approach advocated by Royce seeks a maximum of intervention at every conceivable level of software development by those who impose and assert software development methodologies. In this way, the costly freedoms often exercised by software developers bent on maintaining an old-style guild or shop attitude in the workplace (often disguised as "pride in individual workmanship") is eliminated. Engineering methodologies replace the personalities and, indeed, even the personhood of the lone software developer, and the organization's top managers are ensured that their control of the working environment will not be challenged.
Such a summary of the ultimate implications of the application of a UML management methodology as a replacement for the "culture" of development organizations is much needed. The high-level, abstract discussions of the real reasons for the use of corporate educational efforts to "normalize" software developers ("workers") usually veil the real intent. Royce has veiled nothing.
The message rings out clearly: software development as a realm of individualized creativity and exploration is now a thing of the past. Software companies must impose conformity and Taylor-like authoritarian control. Software developers should be made to realize that they are nothing more than cogs in a wheel, and that management is justified in intervening in every aspect of their working life. Only through such measures will companies reach the efficiency required for survival in a competitive economy characterized by a break-neck pace of product innovation.
Probably the only criticism to be offered is that the book is not altogether open in its declaration of intent to its assumed audience. While the reduced status of the engineer is clearly portrayed, the extent to which the "method" likewise demands the conformity of the manager is left unstated. But then those embracing such a total model of technical management may be assumed to tacitly acquiesce to the notion that the ultimate goal of efficiency management models in technology is to entirely eliminate personalized cultures in the companies that embrace such models.
An excellent work!
by Pete McBreen
- Paperback: 224 pages
- Publisher: Pearson Education; 1st edition (July 19, 2002)
- Language: English
- ISBN: 0201844575
- Product Dimensions: 9.2 x 7.4 x 0.6 inches
- Shipping Weight: 1.0 pounds.
- Average Customer Review: based on 8 reviews. (Write a review)
- Amazon.com Sales Rank: #346,959 in Books
Entertaining debunking of XP mythos, but not concrete enough, November 28, 2003
The biggest thing I liked was that it didn't just focus on XP, but also hit on a lot of other methodologies, doing some comparisons and contrasts. Expect to understand what all the hubub is about after going through it, without needing to buy into any of the other Agile background books first. You will probably also be able to take away a high-level piece or two of advice from it.
Reviewer: Lars Bergstrom "LarsBerg" (Kirkland, WA) - See all my reviews
It's not something I would purchase, though, because it stays pretty high-level through much of the book, and doesn't really have much reference material value. I was also a bit dismayed that he hadn't run a project with XP yet. He cheerfully admitted it in the introduction, and his reviewers were all of the hardcore folks associated with XP; however, that still gave me the same feeling as I would get reading a book entitled Questioning Low-Fat Recipies from the Two Fat Ladies, where they claimed they'd never tried any. Sure, they're FAR better cooks than I am. And probably see more different types of recipies in a given week than I will in a year. But I just would get the feeling I might be missing the whole picture and that too many of the judgements are value-laden and not backed by concrete examples of things that went wrong in his XP projects.
Also, it was weird for a book this small, but I felt like it repeated itself in a couple of the 'summary' end of chapter sections, especially near the end of the book.
I really like what Pete McBreen is presenting but I really didn't like the way he presented it.
I have 24 years of experience as an IT professional and have worked for some very large corporations and a couple of very small corporations. I've seen a lot.
In my opinion, much of what McBreen suggests would never get off the ground at any company for which I've worked. Some of what McBreen says has been around for years. I did come across some things that I am glad to finally see in writing. And of course, he wrote about some things that I hadn't encountered in my career.
Unfortunately, I don't feel he gave a convincing argument supporting his core position even though I think he is correct. But then, I felt that way before I picked up the book.
I think he's on track with some of his recommendations and totally wrong in some of his other recommendations.
I think this is a fair first attempt to present
this view. I hope he or someone else makes another attempt and does a better
job of it.
Programmer as Artisan, not Engineer, December 17, 2001
|Reviewer:||"tekwallah" - See all my reviews|
Software Craftsmanship: The New Imperative revealed the one important fact about how software engineering was derived from giant government projects in the 60's and 70's that I didn't know: those projects included building the hardware on which the applications would eventually run. The reason for the emphasis on long, detailed requirements and design documentation is that this was the best use of the dead time software engineers had while the machine and its compilers were being constructed. As soon as the box was ready an army of coders was given the detailed design documents and converted them page-by-page into source code.
Programmers who have ever wondered why they were being paid high salaries and then treated as mindless drones now have an historical explanation.
Pete McBreen isn't the first person to question standard procedures for developing commercial software. The Open Source movement has proven that high quality, useful software can come from developers using no specification documentation at all. The eXtreme and Agile methodologies have shown it is acceptable for specifications to change during the course of the project: Customers will be more pleased with the final product if they can revise their requirements as they see the product developing.
So who could possibly be holding on to a methodology that is demonstrably inappropriate for modern small software groups developing commercial products? Mr. McBreen fingers managers whose pay and prestige depend upon head count. Turning every project into a relay race with analysts, designers, programmers and testers guarantees many billable hours while intellectual property is passed on from group to group. Preferentially hiring young, inexperienced programmers and capping the salary rate ensures a bloated staff with high care and feeding needs. It's a provocative assertion that will certainly engender debate.
McBreen says he wants to join in the public conversation that already includes the voices of Richard Stallman, Linux Torvalds and Kent Beck. His intelligent analysis of the origins of classical software engineering and why it is no longer a good paradigm for commercial software development will help keep that conversation informed and productive, as well as lively.
* Books mentioned by Mr. McBreen include:
The Pragmatic Programmer by Andrew Hunt and David Thomas ISBN: 020161622X
The Inmates are Running the Asylum by Alan Cooper ISBN: 0672316498
done, March 7, 2001
B. Scott Andersen (Acton,
MA USA) -
See all my reviews
The Pragmatic Programmer is a collection of ideas, observations, and recommendations for software developers. Throughout the book, they highlight these notions in a set of numbered tips, about 70 of them, which are collected on a single tear-out card situated in the back of the book. Just reading the tips, without reading the text of the book, might make these gems seem trite, empty, and obvious. But, they're not!
Many of the tips actually build upon previous ones, like tip 4: "Don't live with broken windows", which urges programmers to fix problems and clean up messes, and tip 20: "Keep knowledge in plain text." With some books like this you can skip around--but this one is better read from beginning to end.
There is plenty of ideas to consider, agree with, and, perhaps, disagree with, too. You can also feel a little passion. "Conventional wisdom says that once a project is in the coding phase, the work is mostly mechanical, transcribing the design into executable statements. We think that this attitude is the single biggest reason that many programs are ugly, inefficient, poorly structured, unmaintainable, and just plain wrong." Hooray for authors who take a stand and then back it up with well reasoned arguments!
book but too shallow, February 6, 2005
|Reviewer:||a reader - See all my reviews|
Micah Spears (San Antonio,
See all my reviews
Essentially, the book is a collection of "lessons learned" from the authors' perspective. If you're a software hobbyist, this book might be a good read. However, if you dare call yourself a software engineer, woe betide you...
overrated, November 8, 2003
|Reviewer:||practicing software engineer (San Jose, CA USA) - See all my reviews|
The preface is good, February 4, 2003
Paul Epps "Trained Professional - Do
Not Attempt" (Irvine, CA USA) -
See all my reviews
|Reviewer:||Larry Musa (Las Vegas, NV United States) - See all my reviews|
Having said all of that, there are good ideas to provoke one's computing thinking in this book...and so while I would recommend it, just be careful to examine their suggestions critically before adopting them.
reading, but light compared to Steve McConnell, December 21, 2001
|Reviewer:||Robert Barnes "email@example.com" (Auckland New Zealand) - See all my reviews|
However I've given it only three stars. My favourite book on programming, "Code Complete" by Steve McConnell, is equally readable, but covers similar ground in far more depth. I make Code Complete required reading for my programming teams. The Pragmatic Programmer doesn't make it past "Suggestions for further reading".
a waste of time, April 13, 2001
Reviewer: A reader
The very first tip of this book is worth reading "tip 1: care about your craft". From there it goes down hill, never really focusing on anything in particular, it tries to be a general guide to good programming practice, but also teeters dangerously on the edge of a self-help guide. "tip 5: be a catalyst for change", "tip 10: its both what you say and how you say it".
The carpenter analogy is so old and tired. Technology and software development are based on scientific research at the university level, and a lot of really smart people outside academia. If you want to be great, read what they have to say, (and not 2 dweebs who tell you to think about your editor as a plane or saw)
There is something disturbing about this book thats hard to pin down. If you're a serious developer you might know the type of programmer this book appeals to. Its usually the sweaty perl programmer with a flannel shirt on in your shop with a lot of philosophies about development. They write 8 lines of impossible-to-maintain hieroglyphic and call it an application.
If you're a serious developer working in a current platform like J2EE, don't get this book...its harmful, coming up with pointless new terms like "orthogonality" which just add more junk terms to the programming community. They also recommend you learn a new language every year, as if it weren't difficult enough to keep up with one enterprise level platform. This book has a very dated quality in that respect. It does get to some current development issues like refactoring, but glosses over them completely.
If your are new to programming maybe its a good idea to give it a try. There are a few points that make sense, but if you're not completely hopeless you should eventually discover them on your own.
disappointing!, December 14, 2000
|Reviewer:||Greg Tomkins (Vancouver, Canada) - See all my reviews|
if you're looking for something interesting, "the mythical man month"
is a lot better, even though its dated. "inmates are running the asylum"
by alan cooper is also great in that it creatively and productively challenges
many of the old saws that books like "pragmatic programmer" trot out time and
time again (i particularly like Cooper's rant against letting customers dictate
design decisions and product paths).
rubbish!, May 18, 2000
|Reviewer:||Jamie Oglethorpe (Johannesburg, South Africa) - See all my reviews|
Programming is a rapidly changing craft. A machinist can learn to work a lathe or a milling machine, and expect that his knowledge will stand him in good stead for the rest of his working life. Not so for the craftsman programmer. Ours is a new craft. We are still learning how to do it. Having survived in the game for a decade or two, and having learned dozens of languages, operating systems, database management systems, transaction processing managers, editors, we come to the realisation that this is a hard game. Each of us learns skills that help us cope with all that change. We learn basic programming skills. We go on learning them. We learn to see what is coming, and move in anticipation. We learn what is important, and what is not. We watch those who are successful, and try to emulate them. We watch the unsuccessful with horrid fascination, and try to learn from them also. "There but for the grace of God go I!"
I don't know how to make an object oriented design. I can do design sketches. So I start from there. I build my system, dealing with the problems as they arise. I rely on my experience to keep me out of trouble. When I see commonality between two classes, I take the opportunity to refactor and eliminate the commonality. I am quite happy to rewrite any piece of code to make it better. You know what happens? I end up with a well-designed system despite myself. I am an opportunistic programmer.
I saw the title of this book, and thought: "That's me!"
So I bought it. What a disappointment! It is full of platitudes. It reads like a writer's style manual. It is good to do things this way. It is a bad idea to do it that way. It has no meat to it, no depth. If you want to know more about the topics they discuss, you won't find it in this book. You won't find much of it in the references either.
Let me quote a typical example from the section entitled "Text Manipulation". "Pragmatic Programmers manipulate text the same way woodworkers shape wood ... We need a general purpose text manipulation tool ... Text manipulation languages are to programming what routers are to woodworking. They are noisy, messy, and somewhat brute force. Make mistakes with them, and entire pieces can be ruined ... in the right hands, both routers and text manipulation languages can be incredibly powerful and versatile..." What rubbish! The analogy flows on, and is followed with the advice to learn a text manipulation language, and a list of things possible with such a language. There is not one practical example.
This continues for section after section. In Appendix A: Resources, the authors say "The only reason we were able to cover so much ground in this book is that we viewed many of our subjects from a high altitude. If we'd given them the in depth coverage they deserved, the book would have been ten times longer." All I can say is that they should have covered ten times fewer subjects, to the depth of coverage they deserved.
A journeyman programmer wanting to become a master is advised to study at the side of a master. Buy Kernighan and Pike's The Practice of Programming.
Naive and unrealistic - don't waste your money, March 31, 2001
Reviewer: Salah Boukadoum (see more about me) from Dallas, TX United States
The approach described in this book is great if you have a team of highly professional, self-motivated, naturally cooperative people with a clear understanding of a common goal who all behave as mature adults with the company's best interests dictating their decisions. In other words, this is a book about how to manage people and situations that require no management to begin with.
If on the other hand you have to manage a real-world team of people who actually have to finish projects that earn real money for a real company with real time constraints, real technology challenges, real customer issues, real personnel issues, and real politics, this book is useless.
Everyone already knows the obvious issues around productivity - noise is bad, useless meetings are bad, cramped spaces are bad, overbearing policies are bad. You don't need a book to figure that out.
There's nothing in this book to help you manage real world team problems. For a book with principles that can actually be applied in the workplace, try Andy Grove's book High Output Management. Don't waste your money on this one.
A Discipline for Software Engineering (Sei Series in Software Engineering)
by Watts S. Humphrey
The apotheosis of meaningless measurement, June 26, 1999
Reviewer: j.bach from
Front Royal, Virginia
Sometimes I question the need for philosophy, then a book like this comes along and I remember why philosophy is important. Philosophers do us the service of carefully analyzing premises, claims, and all the varied artifices of thought. Philosophers notice the clouds beneath the castle. Watts Humphrey's book is in need of a philosophical overhaul. It is a fine expression of 19th-century ideas about scientific management and the nature of human cognition, but takes little note of modern revelations about how human minds work, and how software design happens.
The book is an ode to measurement. Humphrey doesn't justify or explain his measurement theory, though. He seems more intent on telling us what to do than on helping us ask questions like "What do these numbers mean?" He proposes ways to measure quality, but not ways to understand goodness; ways to measure productivity, but not ways to understand productivity in relation to our ambitions. Reflection, inspiration, collaboration, dialogue, discovery, invention, ingenuity, all of these vital processes are ignored in his calculus. But since his calculus is embedded in a prescription for what we're supposed to do, anything left out is driven underground (or underwater, like an animal that doesn't get a ticket for Noah's Ark). It's a good thing for the technology that so few people are disciplined in the way Humphrey proposes.
I just want to point out that there is an alternative to the Brave New World of Watts Humphrey and the SEI. Search for books by Gerald Weinberg and you'll find a polar opposite view of software engineering as a social and cognitive discipline. Weinberg's book on measurement "Quality Software Management, Vol. 2: First-Order Measurement" is a must read.
I also recommend "Things That Make Us Smart" and "Cognition in the Wild", two books that startled me by showing how much cognitive psychology could help the software engingeering craft, if ever we computer people but wake up and take notice.
Discipline is important in any search for excellence. Let's build our discipline on a sound and meaningful foundation, eh?
Textbook Binding - 352
pages 1 edition (October 13, 1999)
Addison-Wesley Pub Co; ISBN: 020161622X ; Dimensions (in inches): 0.70 x 9.22 x 7.40
Amazon.com Sales Rank: 2,733
Avg. Customer Review:
Number of Reviews: 17
|Are you programming or hacking?||
June 3, 2000
|Reviewer: Steve Hayes (see more about me) from New York|
|...and what's the difference? I've often
felt that the difference was attitude. Programmers (or "professionals"
if you prefer) were continually thinking about what they did, why they
did it and how they could do it better. And I don't just mean searching
for a new language ("maybe I should learn Java this week?").The rest
of us are just tooling around doing the best we can and wondering why
it sometimes doesn't work.
"The Pragmatic Programmer" is clearly written by and for professional programmers. Reading it with attention will force you to think deeply about the way you develop software. If your first response is "but this isn't pragmatic" or "I don't have time to do these things" then I encourage you to think again. Perhaps the barrier is change itself. Sure, applying the practices in this book may slow you down in the short term (you always go slower when you're learning a new skill) but the benefits to establishing these practices as habits are enormous.
We are working through this book as part of a weekly study group at our office. This seems to be a great way to investigate things you're uncomfortable. And I don't agree with every practice in this book, but please think about them as deeply as you can before you reject them!
Whenever I interview someone I ask them what book has most influenced the way they develop software. If they answer "The Pragmatic Programmer" (or "Zen and the Art of Motorcycle Maintenance") then they have the job!
|A perfect guideline for programmers||
October 29, 1999
|Reviewer: Thanh T. Giang (firstname.lastname@example.org) from Pearl City, Hawaii|
|This book is decades overdue. Whether
you're a beginner or a seasoned programmer, it's not too late to learn
effective and efficient ways to design and code industrial strength
applications. In today's competitive software environment, one cannot
risk working without the techniques presented by the "Pragmatic Programmers."
Andrew Hunt and David Thomas definitely know what they are talking about. Each chapter emphasizes new ways to improve and strengthen your current skills. If programming is your intended profession, don't waste another day doing things the wrong way. Start with the right frameset and place yourself among the "Pragmatic Programmers."
|Wisdom and Humor -- what a rare find||
May 31, 2000
|Reviewer: Holm Court (see more about me) from NYC|
|This is, simply, a wonderful book. It
is a book that celebrates the real depth of great programming -- something
that is too often forgotten or ignored. This is not an idiot's guide
to anything -- it is a remarkably entertaining set of dozens of tips
to becoming better at what you do, especially if that happens to be
The tips are deceptively simple at times, but only a truly naive or inexperienced reader would miss the rich depth that their combination presents. In fact, that is the real beauty of this book -- it does not present some short-lived miracle-cure approach -- instead, it weaves together small bits of wisdom and practical advice into a powerful work-style.
They have some controversial views -- these authors are witty and opinionated -- but agreeing or disagreeing with each individual idea is not the point -- "seeing the forest" is.
There are numerous specific code examples, but the book is a fun and easy read -- strangely, I also think it would be a wonderful book for someone who is NOT a programmer, but who works with them, perhaps a business manager having a major system built. Even skipping all the really technical parts, it would be a wonderful set of benchmarks to assess how good your programmers really are -- much more powerful than "he has 3 years of C++, 2 years of Linux"...
I am hoping this writing team will follow this book with some specific guides as well, but this one is destined to be a classic. These guys really know what they are talking about, and, as a wonderful bonus, they are terrific writers, as well!
The book has gotten great reviews on slashdot, as well as a couple of programming magazines, including Dr Dobbs and Software Development -- they were well deserved. Buy IT!
Patterns of Software Tales from the Software Community
Amazon.com Sales Rank:
Avg. Customer Review: Number of Reviews: 4
A painfully honest look at life
in the software business
from Portland, Oregon USA
|There are many people who can operate
a word processor with sufficient skill to create a book about computers
and software that someone will publish; there are only a few published
authors in our business who are also truly good writers. Richard Gabriel
is one of the latter. In "Performance and Evaluation of Lisp Systems,"
he showed he could create a lively book on possibly the single most
esoteric subject imaginable. In "Patterns of Software," he demonstrates
his skill in essays ranging from patterns in Turkish carpets to the
hard lessons of software startups, from the joys of riding cross-country
in a Corvette at 125 mph to the often demeaning life of a graduate student.
The last essay alone, "Money through Innovation Reconsidered," would justify purchase of the book. Gabriel does a masterful job of analyzing one of the apparent paradoxes of software engineering: that the "best-engineered" software products can be spectacular failures in the market (e.g. Common Lisp, for reasons Gabriel dissects in depth; and, remember Ada?), while the most successful products have a ball-of-mud-that-just-grew quality (yesterday DOS; today Linux).
The more time you have been schooled in "the right way" to build software, the harder this truth is to accept; but it is truth nonetheless, for reasons Gabriel lays out succinctly. The essay deserves a place near Arthur C. Clarke's classic SF short story "Superiority." Read both and you'll see the connection.
Speaking of connections: many of the essays in "Patterns of Software" deal with Gabriel's multi-decade fascination with the work of Christopher Alexander on finding the underlying patterns in architecture that make buildings pleasing and habitable, with Gabriel asking the eminently reasonable question whether such patterns also exist for designing software that is pleasing to use. These essays are stimulating, but have a vaguely surreal quality when one notes that Gabriel has spent most of his professional life in Palo Alto, Alexander most of his in Berkeley, but -- according to Alexander's foreword to "Patterns of Software" -- the two have never met in person to discuss their ideas.
Should either happen to read this review, I will make
Gabriel and Alexander the following offer: pick a place in the Bay area.
Make sure it has lots of "the quality without a name" (Alexander's phrase
for what other people would call a lived-in quality or sense of rightness).
The kind of Italian place in North Beach where the Beat poets used to
argue 'til dawn would do nicely. Let's have dinner. I'll pick up the
tab. It will be worth it.
Many fascinating anecdotes about
real-world software design.
Reviewer: Michael C. Vanier
from Pasadena, California
May 20, 1998
|This book is a very interesting
and entertaining read for anyone who is involved (or is thinking of
getting involved) in serious software development. Despite the title,
only the first section of the book is devoted to pattern languages.
The rest of the book is a selection of stories and musings about
issues such as computer language choice, language size, running a software
company, and the author's own personal history.
The material on patterns is interesting in that it focuses on the founder of the patterns movement, the architect Christopher Alexander. Gabriel tries to find parallels between successful software designs and successful buildings. He identifies several key ingredients, particularly "habitability" and "piecemeal growth".
Essentially these boil down to the idea that the users must feel comfortable with the software, and it must be possible to extend the software incrementally as needs change. Gabriel has a refreshing skepticism about "silver-bullet" strategies and his insights often go against conventional wisdom, which makes for thought-provoking reading. The last sections of the book are an account of his path through academia and his experiences as the founder of Lucid, Inc.
There are a lot of horror stories here, which are
fascinating and frightening to read. My only complaint with the book
is that it seems so focused on negatives (e.g. what can't
be achieved, how bad people will shaft you every step of the way)
that it gets pretty depressing. I wish there had been a couple
of success stories along the way, or at least a less gloomy outlook.
Some of the pessimistic predictions (which are several years old
by now) also seem pretty silly in retrospect, such as the prediction
that C will be the last programming language. Still, this is
a very interesting book for software developers and has a very sobering
effect. --This text refers to the
recommended when you
want to contemplate a software career
Reviewer: Mark R. Thomsen (email@example.com)
from Torrance, California
October 17, 1997
|I spied this book and picked it up for
two reasons: "patterns" and the author. I know something of Gabriel's
career through Lucid. He is a certified software wizard.
And I was curious if anyone would write something on software patterns
that would transcend the obvious and perhaps even find a real tie-in
to Alexander's architecture work. And then there was a foreword by Alexander.
And a tale of Gabriel's rising from failure (or a bad position) again
again. Unique. Interesting. So I bought it and I read it one afternoon.
There is nothing there for immediate application.
No programs. No recipes for overnight success. Just contemplation
on how things work. Software. Academia. Industry. And, yes,
a bit on life. It does something so few books do. It gives you new perspectives
and new questions, and gets you creating new perspectives and asking
new questions. It makes you think. At least it did me. One further point.
So few in the software field can really write well. Gabriel writes well.
Software trekkies compile at
Reviewer: A reader
March 4, 1997
|You can't begin with the footnotes,
looking for crusty anecdotes: the only one merely is an explanation.
You can't directly jump to the index either, aiming at your favorite
hottest topic, cross jumping from subjects to keywords, reading paragraphs
while thinking you thouroughly read the book: there are only references
at the end of the book. And you'd better go through these carefully,
to get the taste of what you're about to read: architecture, philosophy,
turkish carpets, epistemology, greek wars, biology, style and... management,
software engineering and programming languages. Indeed, you may think
that a book whose title targets one of the hottest topics in software
engineering (one topic eligible for an appearance in the well-known
"wired" column --- although it hasn't yet, controversially aligned with
something you'd better be "tired" of) should go into the details of
the programming and software tricks you need to boost your own project.
Well, Richard Gabriel's opus does not. Navigating freely through the
essays, you eventually realize Gabriel has a more ambitious vision than
teaching his lattest hacking techniques: bridging architecture and software.
That is, art and science. Indeed, when stuck with problems in your own
field, why not try to learn from other fields? And, in particular, why
not try to learn when the words, the processes, the results (and even
the failures) so closely echo with those you experience in your day-to-day
activity? To achieve such a difficult goal, Gabriel's "Patterns of Software"
takes you by the hand, stepping the assembly language of architecture
to shed light on that of software. Looking for the realm of beautiful
software in the land of beautiful buildings, Gabriel decompiles the
work of the architect Christopher Alexander who devoted his life to
the realization of beautiful buildings. Gabriel imports architectural
notions and concepts (habitability, piecemeal growth, patterns), aiming
at a suitable instantiation that would make sotware beautiful as well.
Gabriel even finds materials to talk about architectural bugs and spends
an essay (titled "the failure of pattern languages") debugging. And
in a last reflexive effort, Gabriel decompiles himself, his life, and
the company he funded and which later failed, Lucid Inc. But does Gabriel's
bridging succeed? You'll wish to end up your journey with the foreword
written by Christopher Alexander himself, to agree that the question
remains... And that it is not the point. This book is a pioneering brand:
neither success nor failure, simply the user guide to go where no programmer
has gone before. The reading-risk is to become a software-trekkie. Interested?
--This text refers to the
|The single best book on the craft of writing software.||
April 6, 2000
|Reviewer: Tod Gentille from Los Angeles|
|McConnell has read years and years worth of computer science literature and distilled it into an extremely readable format. It is a hefty 800+ pages but you will rip through it and enjoy every minute. McConnell combines wit and valuable information into a gem of a technical book. If you program and you haven't read this book you are doing yourself a great disservice. McConnell also goes to great lengths to avoid dogma. He presents many sides to what sometimes seem like religous issues in programming. He gives you the information to make your own decisions. Trust me, you MUST read this book.|
|"Code Complete" Considered Harmful for C Programmers||
January 31, 2000
|Reviewer: Roger Miller from Mililani, Hawaii|
|Although "Code Complete" is in many respects
a worthwhile compilation of experience that is otherwise difficult to
find in one place, when it comes to specifics of C programming its virtues
are marred by numerous errors and un-C-like style. It is clear that
the author had little experience, and was rather uncomfortable, with
the language. Classic beginner blunders like incorrect end of file tests,
macros which produce syntax errors in some contexts, sequence point
errors, and confusion about null pointers are generously represented.
We are advised to use names which begin with underscores (in ignorance
of the C standard) and "cute" macros like "#define AND &&" which experienced
C programmers hold in low regard for good reasons.
Granted, this is not written as a C programming text. Still, there is lots of C-specific advice and C programming examples, and readers deserve a more professional treatment. Given the popularity of this book it would be nice to see its flaws corrected in a second edition. In the meantime read it for its general advice, but learn your C from the experts. (Kernighan & Ritchie, Harbison & Steele, and Steve Summit's book length FAQ won't lead you wrong.)
|MOST STUFF ARE ONLY USEFUL FOR COLLEGE FRESHMEN||
December 24, 1999
|Reviewer: Michael Lim (see more about me) from Sillicon Valley, CA|
|Like a few previous reviewers said, this
book contains very little new materials for 857 pages if you either
are a senior student in Computer Science major or you have completed
one course in S/W Engineering. This book is only useful for freshmen
who want to be ahead of the game. Some bad things about this book are
that it takes almost 900 pages to say what can be said in less than
a few hundred pages. Furthermore, many things mentioned in the book
are just common sense that you should have learned/known by the time
of your senior year. The worst thing is that a lot of times the author
only mentions what exists, but doesn't explain to readers what it is,
what it is good for, or how to do/use it.
Good things are that it has a few good chapters regarding S/W construction phrases. These are probably those chapters that offer you new insights. Again you have to read a great number of pages to learn a few things.
My advice is to check it out from the library first. Then decide if you should pay for it. Hope the book will work better for you. If you have read this book, give me/others your review/opinions.
|Great book for beginners only||
October 8, 1999
|Reviewer: Mike23 from Austria|
|Junior programmers will probably enjoy this book, but profi programmers won't find more than 5% of this book useful. There is too much theory, and the whole book would fit to 300 pages (instead of 840). Buy this book if you dont have more than 2-3 years of software-construction experience. This book would deserve 5 stars, when you change the name to: "Code complete: a practical handbook of software construction for BEGINNERS". For experienced programmers is 3 stars rating of this book more than enough...|
|***** Excellent catalog of source code transformations||
March 16, 2000
|Reviewer: firstname.lastname@example.org (see more about me)|
|Learn how to improve your code using 73 refactorings. Sixty seven percent (49/73) of the refactorings are specific to object-oriented languages such as Java, C++, and Smalltalk. Refactoring promotes a healthy approach to maintenance programming. "When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature." Fowler's systematic approach and insistence on regression tests insures that each refactoring will not break any existing code. The constant application of appropriate refactoring results in reliable and clear source code. Some refactorings are opposite pairs such as "Add parameter", "Remove parameter" and "Replace Delegation with Inheritance", "Replace Inheritance with Delegation". A refactoring may have significant downsides, for example "Preserve Whole Object" increases coupling and "Replace Temp with Query" decreases performance.|
|***** Beware, paradigm shift ahead||
August 5, 1999
|Reviewer: Eileen Sauer at email@example.com (see more about me) from Tampa, FL|
|When I first started reading this book, I Laughed. Having garnered a reputation as a "Mad Slasher" of badly written code (say, 700 line programs down to 150 lines or less), it was wonderful to see the principles I'd learned over the years codified into a readable catalog of techniques that should be in everyone's arsenal. Required reading for those new to OO development, and a new vocabulary (similar to what "Design Patterns" did) for everyone to share their insights. BRAVO|
|** Good Information But Extremely Poor Delivery||
March 15, 2000
|Reviewer: gso-software-engineer (see more about me) from Greensboro, NC|
|This book contains some good information on how to improve yourexisting code without rewriting it entirely which is a nice departure from the norm of most of these UML-type books which advocate totally changing the way you design and build software. Not that the Unified method of designing and building is bad, its just that its hard to change the way this is done in an organization when you're not in charge of the organization. Mr. Fowler has put forth a mechanism for improving the design of existing code while adding functionality to it. And the information, once culled from the surrounding text, is extremely useful. It's not paradigm shift. And it's not a companion to Design Patterns - Fowler mentions the Design Patterns book throughout his text but this book is certainly not written for the same audience. Fowler never once gives an example where he converts bad code into good by utilizing a pattern from the Gang of Four's book. The book is useful for ANY object-oriented language even though he uses Java in his examples the principles map easily to C++ and SmallTalk. Almost all of the techniques are common sense and yet he spends the bulk of this book explaining in simple terms how to perform them. For each "refactoring" he capably provided a two or three sentence overview of the process, and a code fragment or class diagram exemplifying the technique. These summaries and figures are excellent. But his tone becomes condescending as he painfully explains the process of performing the code improvement. For instance, Extract Method, the first technique in the book, is succinctly described with: "[If] You have a code fragment that can be grouped together...[then] Turn the fragment into a method whose name explains the purpose of the method." Pretty simple and probably not quite enough to totally understand what he is talking about. But then he has a wonderful little code fragment that illustrates it perfectly. This requires about half of one page. But he spends four and a half more explaining how to perform this simple cut-and-paste. 270 Pages of this 418 page book are spent describing 72 techniques in this kind of excruciating detail. Eight very useful pages are spent describing the bad "smells" in your code that lead to these "refactactorings". Another 110 pages is spent telling you how to justify the work to your boss, encouraging you to do it whether or not your boss approves, advocating a "test-small-change-test" paired programming technique characteristic of Extreme Programming. The final 30 pages are written by the other contributors. Altogether, I think this book should be "refactored" into a 100 to 150 page soft-cover manual reminiscent of Scott Meyers' Effective C++ books. If you're looking for Design Patterns: Part 2 this isn't it! END|
|**** Very valuable contribution towards Programming folklore.||
July 22, 1999
|Reviewer: Jaideep Baphna (see more about me) from Cambridge, MA|
|First one small complaint about this
book: It introduces the notion of "bad smells in code" which are nothing
but "Anti-patterns". Why introduce another new term? The notion of "Antipatterns"
was introduced by another book with that title. That book too handled
some of the issues of "Refactoring" although at different level and
hence should have atleast been mentioned in the bibilography.
Interesting thing is that the "Catalog of Refactoring" in this book is in inverse format of the "Catalog of Anti-Patterns". That is not a bad thing though.
Many thanks to all these authors (like the GoF and Fowler-Beck-gang) who giving the OO programming world a higher level vocabulary, by giving names and cataloging simple types of changes that you make to your code to rejuvenate it. That is a very important contribution towards documenting valuable programming folklore.
The book is pretty focused. The authors talk of little Refactoring. And don't digress into suggesting ways to handle Architectural or Infrastructural Refactorings (like say moving from Monoliths to N-Tiers). That makes it a fun yet valuable read.
Luckily, there's more good news as well -- Brian Kernighan and Rob Pike have a new book out. Their initial joint effort, 1984's The Unix Programming Environment, was the first comprehensive introduction to the standard UNIX toolset, and in many ways remains the best. It, and three other books with Kernighan's name on the spine -- The C Programming Language, Software Tools, and The Elements of Programming Style -- had a lot to do with UNIX becoming the world's most popular operating system. (Yes, I know Windows is more widely used: I said "popular" on purpose.) The Practice of Programming recapitulates and updates the best parts of those four books. Coding style, interface design, testing and debugging techniques, and ways of improving program performance are discussed lucidly and authoritatively. As a bonus, some of the examples are implemented in two or more of C, C++, Java, Awk, and Perl, so that Kernighan and Pike can compare and contrast those languages's strengths and weaknesses. Upon reflection, however, two things about this book left me feeling slightly depressed. The first is how little software development practices have changed in 20 years. Most programs are still written without ever having really been designed, and tested haphazardly if at all. In a lot of ways, we have changed less since the 1970s than the big car manufacturers or grocery chains. The second thing that depressed me is that I'll probably be able to say the first thing again 20 years from now, when the Doobie Brothers are back on the radio for the third time...
Software Development Checklists -- These checklists are excerpted from Code Complete (Microsoft Press, 1993) and Rapid Development (Microsoft Press, 1996) by Steve McConnell. Portions are Copyright © 1993-1996 Steven C. McConnell.
Programming on Purpose: Essays on Software Design Plauger, P. J.$33.00
Software Projects Evolutionary vs. Big-Bang DeliveryRedmill, Felix $49.99
Structure & Interpretation of Computer Programs Abelson, Harold; Sussman G.; Sussman, J.
Beware any book of Edward Yourdon. This guy is a great speculator. But entertaining writer. You should not believe any single word ;-)
*+ Time Bomb 2000 : What the Year 2000 Computer Crisis Means to You! (Yourdon Press Computing Series) -- Edward Yourdon, Jennifer Yourdon; Paperback
The message of this book is clear and simple -- I want your money ;-)
Rise & Resurrection of the American Programmer (Yourdon Press Computing Series) -- Edward Yourdon; Paperback
He is not that bad as Yourdon -- he managed to wrote a decent book about PL/1 and later an interesting book about psychology of computer programming :-). But that was it. Attempt to write more books was counter-productive.
Programming As If People Mattered: Friendly Programs, Software Engineering Borenstein, Nathaniel S.$16.95
Usability Inspection MethodsNielsen, Jakob; Mack, Robert L.
Managing Risk: Methods for SoftwareSystems DevelopmentHall, Elaine M.
Software VisualizationProgramming As a Multimedia ExperienceStasko, John
Software Runaways: Lessons Learned fromMassive Software Project FailuresGlass, Robert L.
Debugging the Development ProcessMaguire, Steve$24.95
In Search of Clusters, 2nd ed.Pfister, Gregory F.$44.95
Survival in the Software JungleNorris, Mark$49.00
Surviving the Top 10 Challenges ofSoftware Testing: A People-Oriented ApprPerry, William E.; Rice, Randall W.$27.95
Software Engineering : A Practitioner's Approach -- Roger S. Pressman;
Hardcover Software Engineering Classics (Programming/General) -- Steve Maguire, et al; Paperback
Software Engineering : Theory and Practice -- Shari Lawrence Pfleeger; Hardcover
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017