Programming Books

I agree with many of the other reviewers - this book is great. I recently got Mathematica and found the imbedded Help browser a little cryptic at times. I purchased Mathematica Navigator after reading many of the reviews here. I haven't read the book from cover to cover, but instead use it as a reference after having read chapters 1 through 3.

I'm studying Matrix algebra, so I skipped to Chapter 18 and worked through the examples without any problem, save a small error on page 467 where an upper case P was typed in lower case.

Highly recommend for anyone wanting help making the most out of very powerful software.

Very well written and full of useful information to start learning Mathematica. It covers all the foundamentals.

This is a GREAT reference book. You won't learn how to program Mathematica from it. You will learn an amazing amount about how Mathematica works by reading it. If you don't believe me, check out it's thorough explanation of cubic splines. It's better than the Mathematica Help. It also comes with the complete book which can be installed in the Mathematica help system.

There is, literally, a wealth of information to work with in this book.

I would also strongly recommend getting An Introduction to Programming with Mathematica, Third Edition. This is a first rate "course in a book" for programming.

There are other books which are good. Between these two books, you will have an amazing arsenal to work with!

Paul

Mathematica is an excellent program, with good built-in and online documentation - although many feel the Documentation Centre in version 6 is not as good as the Help Browser in version 5.2. But sooner or later you will find a problem for which the official Mathematica documentation does not help. The program can then be very frustrating, as the syntax is complicated and error messages can be very cryptic. Help online is painfully slow, as the official resource, the news group comp.soft-sys.math.mathematica (Mathgroup), is moderated, so help requests have to be approved before they will appear. (The newsgroup sci.math.symbolic is sometimes helpful and since its not controlled by Wolfram Research, posts appear immediately). Hence Mathematica users will need one or more good books - more so than with other similar programs such as Maple or Matlab.

In addition to the book Mathematica Navigator by Ruskeepaa, I own several other books on Mathematica, including:
* The Mathematica Book, Fifth Edition by Stephen Wolfram
* The Mathematica Guidebook: Programming by Michael Trott.
* The Mathematica GuideBook for Symbolics (w/ DVD) by Michael Trott.
* Schaum's Outline of Mathematica by Eugene Don
* An Introduction to Programming with Mathematica, Third Edition by Paul Wellin
* Programming in Mathematica (3rd Edition) by Roman Maeder - I also own the first edition.
* The Beginners Guide to MathematicaRG, Version 4 by Jerry Glynn and Theordore Gray

plus a few more old books I've either had a very long time or bought very cheaply on Amazon.

Given the choice of only one book, I would choose Mathematica Navigator by Ruskeepaa. It comes with a CD-ROM which has the whole contents of the book, which may be integrated into Mathematica's help system. It's not unique in that respect, as so do Micheal Trott's Mathematica Guidebooks, but they have far too much irrelevant material in them. Ruskeepaa's book sticks to important facts about Mathematica. The book covers a wide range of topics. Sometimes I wish in more depth, but the book offers a good compromise between width and depth. In particular, the information on writing Mathematica programs is far too short, so its unlikely to satisfy someone wanting to write a major Mathematica package. For writing packages, Programming in Mathematica (3rd Edition) by Roman Maeder based on Mathematica 3 is arguably still the best, although Maeder's 1997 book is very old.

The only significant fault I can find of Ruskeepaa's book is its age. Mathematica 6 is a really major upgrade from 5 with many functions now built into the kernel which previously needed to be loaded from packages. Many functions or options have been deprecated. As such, some of the information is no longer accurate. But given at the time of writing (December 2007) there is no book on Mathematica 6 published, I think Ruskeepaa's book, which is based on version 5, is the best Mathematica users can get. However, if by the time you read this, someone has published a book on Mathematica 6, then it might be worth buying that instead.

I would have given this 5 stars, but it is getting a bit dated now.

I liked the first version so much that I bought this second edition also. The first edition was based on Mathematica 3 but this second edition is based on Mathematica 5 (Mathematica 6 has only just shipped within the past 2 months).

As did the first edition, this second edition comes with a cd that contains the entire book in Mathematica notebook form. The style sheets used to format the second edition cd notebooks are much cleaner looking than the first.

At anyrate, I definitely recommend the second edition even if you already have the first edition.

This book is like a SQL SERVER 2000 bible for me. It has the most wonderful information in it, clear and easy to understand. I needed to interview for a job and I looked to this book for clarity and knowledge and boy was I enlightened. A must read for a beginner DBA like myself!!!!!

I have been a DBA for a bunch of small sites for many years. Recently I committed to a job w/ a large, online OLTP retailer and needed to fine tune my knowledge of the SQL Server engine.

I was shocked at just how flawed/lacking my knowledge was after reading this book.

Let me first state this sucker isn't for people looking to get by using the Enterprise Manger GUI. This book dissects the inner most workings of the db engine and it's under lying theory. Their is a lot of TSQL. I found myself limited to reading only a small number of pages at a time and then needing a break. The book is that intense and I have a Masters of Science degree as well as MCDBA and MCITP certifications.

Probably my favorite feature of the book is its small size, under 400 pages from tip to tail. I'd suggest this book to anyone wanting an understanding of what they are actually doing in SQL Server when they issue commands from EM. This book should be a requirement for any DBA or DB Designer in my opinion.

This is the best book ever written on performance tuning. Excellent text and very well written too. Thanks a lot.

I have been working with SQL for several years and always felt a bit weak in my understanding of best practices. I have only absorbed a few chapters so far on index structure and execution plans but already I feel like I have fast tracked into the clever peoples class. The layout is excellent and the language unambigous.

I am a SQL Server performance consultant to many large corporations and government agencies. I have read and re-read this book so many times I should know it by heart. Still, I carry it with me on consulting engagements everywhere I go. There is almost always someone at my client's site who wants to improve their performance tuning skills. I show them the book and tell them this is where you start.

I don't know if there will be a version specifically for 2005, but it really doesn't matter much. The central concepts of the book have not changed for SQL Server 2005.

Ken England's writing style is clean and lucid. He can explain complex issues in a remarkably understandable way. His explanation of indexes and strategies of indexing is a great example of readable technical writing. He also has a good understanding of what is important and what is not.

This book is accessible to anyone who has some experience with SQL Server or any relational database. Someone with little experience may not get it all in one pass, but they will be much better prepared for real-world SQL Server performance tuning.

I'm a solo developer, and without this book i would be refactoring my code every few days still.

Thank you RUP for putting my head on straight to understand iterations of the SDLC and apply them to even small projects with few assets.

RUP gives you the tools to understand your system before you write it by iteratively working with the people who will be using the system! Your customers/Users!

Excellent guide to get up to speed with RUP. Having never worked with RUP this guide proved extremely beneficial to get the project started and will be used through all iterations.

I read 'Rational Unified Process - An Introduction' some years ago and found it excellent. I got 'Rational Unified Process Made Easy' in the hope that it would provide some more substance to the ideas from the introductory book. However it didn't seem to really add that much value.

The sections covering each of the major disciplines are useful, as is the guidance on implementing RUP in projects or organisations. In contrast 'Rational Unified Process Made Easy' misses a good summary of the key artefacts.

All up I felt the book was hampered by the desire not to undermine the RUP product that IBM sells.

This book does a great job of showing steps of practical application of the RUP. The book may seem repetitive on a few points, but I feel the points bear repeating. This book has been invaluable in helping cut through the misinformation thrown around by some who have gotten the executive summary of RUP and know just enough to be dangerous. I recently completed a seven-part online course on the RUP that was based on this book. The book did a far better job of making the RUP understandable.

There is plenty of theory written about RUP, but how it should be applied to your role or your project is often misunderstood.
This book not only provides the overview, but the contextual guidance to make RUP work for you.
As a long-term RUP mentor and user, I highly recommend it.

Great book whether you write proposals now or will be doing so in the future, good reference as well.

The book is an easy read and provides me with the needed understanding of developing an RFP and template.

There are literally hundreds of good books on proposal writing, but only a tiny handful on writing RFPs. From among the handful this book stands out for a number of reasons:

(1) It clearly described the RFP process from start to finish - and RFP development is a process with a defined life cycle.

(2) The author goes well beyond the immediate objective of writing an RFP and managing the process by including thought-provoking material on post-award vendor management. This material sometimes escapes the RFP development team who is more focused on getting to the award milestone without thinking about the post-award ramifications.

(3) It's not boring - the writing is lively, and the material is presented at a fast pace. The pace, however, does not leave gaps. Every facet of the RFP process is covered in sufficient detail.

In addition to the above, the approach set forth in this book is consistent with best practices in RFP development. I especially like the copious checklists, the RFP roadmap, and the way illustrations are skillfully used to reinforce concepts and advice.

Note that the focus of this book is information technology and software acquisition. Some of the material is unique to those domains; however, the basic principles and RFP process can be used for virtually any type of RFP, from office services to purchasing furniture.

Overall, this is the one book I recommend for RFP development. If you are an IT professional, regardless of role, the chances are you will be involved in this process at some point in your career, making this book a valuable addition to your library. If you have recently been assigned to an RFP team you should get this book as soon as possible, and use it as your compass and blueprint if your organization does not already have a formal RFP process in place.

I bought this book because I was to lead a group in developing an RFP but had no experience with RFP's. I don't know how this book will meet the needs of anyone with a lot of experience but I am extremely impressed by its readability, organization, and applicability. I'm still working on the project but have gotten good feedback on what I've developed, which I could not have done without the guidance and information in the book. It is logically sequenced and appears to cover all bases, though someone with a lot more experience would be better able to assess this. Impressed? Very.

A great resource for preparation and review of an RFP. A helpful guide for people with and without RFP experience.

Add this to your collection of professional development books; you likely won't be disappointed - but remember, like anyone who is good, they make it look easy.

I'm a software developer and have a lot of experience writing Vision- and "Use Cases"-documents.
Writing these documents is not a big deal, however to make the customers read
"Use Case"-documents and provide feedback is much more difficult. But without feedback
it is not possible for a developer to write correct requirement documents.

I ordered this book because I liked the word "collaboration" in its title. It implies
the importance of working together with the customer in order to get the requirements right.
As I expected the author concentrates much more on the process to elicit proper requirements
rather than on the notations of requirements models such as UML. The best way to collaborate
with customers is to have structered meetings the so called workshops.

The book is divided into following three parts: "1. Overview of Requirements Workshops",
"2. Requirements Workshop Framework", "3. Requirements Workshop Design Strategies". Especially
the 2nd part contains a lot of detailed information and sometimes it is difficult not to get
lost. But part one and three are quit easy to follow.

Only in part one is a chapter which describes the different requirements models.
They are categorized according to their view, focus and level of detail. After reading this chapter you
know when to use which model. "Use Case"-Models are the most popular requirements models.
However, there are software projects in which other requirements model are more appropriate.
This chapter gives you an overview of the 19 different models.
Although a brief summary of every model is provided there is no example. If you want to know
the details of these different models you have to look for other sources of information.

The rest of the book concentrates on the prepartion and facilitation of workshops. A lot of useful
advice is given on how to manage people, content and processes in a workshop. Most of the
content of the book is aimed at facilitors of workshops. If you have nobody in your company who
has the necessary skillset to facilitate workshops, the author recommends to hire someone from
a consulting company, who can do this for your workshops.

On the author's website there several useful templates and guidelines which help you make your
workshops more successfull.

This book is a recommended reading for everyone who is responsible for the success of a software project.

In Requirements by Collaboration, Ellen Gottesdiener shares many years of experience in running requirement workshops. In this area, Ellen might be one of the most experienced facilitators in the world.

The author provides a framework for organizing requirements workshops. The framework is based on getting six Ps right. The Ps are "Purpose, Participants, Principles, Products, Place and Process". For each step it describes typical things that need to be done. First establish a share purpose. Find the right participants for the workshop. Set the principles and ground rules. Decide what work products to create (the book provides an excellent overview of work products used in requirement analysis). Define the requirements for the location and decide where to hold the workshop and decide the process to hold it.

In each steps, the author provides great tips and insights from her experience in facilitating workshops. In the later part, some strategies of requirement analysis are presented and the book ends with some case studies.

Overall, the book is well written an easy to read. The requirement workshop framework, at times seems overly complex and certainly would need to be tailored to the specific situation. However, I think this could not have been prevented when talking about a generic way of holding requirement workshops.

In Agile Development, requirement workshops are one way of doing requirement analysis and spreading the requirement analysis over the whole project. For these kind of workshops, this book is probably the only reference, eventhough the book itself does not cover this very well. Therefore "requirements by collaboration" is a must read for anyone who wants to do requirements workshops.

I found this book to be an invaluable help over the last few years that I have been running workshops with business people and users. It is concise and full of tips and how to's that are of great practical value. I can not recommend this book enough. I am a technical architect who has been thrown into the requirements and the domain traditionally inhabited by Buinsess Analyst and their ilk. I have used this book as a guide to run requirements workshops, business process workshop and scoping workshops. top book.

This book is about running requirements workshops and more. Requirements workshops are an important tool for understanding what you need to build. The techniques in this book will be useful in many other group discussion settings, and will help you have more productive meetings. The book discusses, among other things, roles in workshops and decision rules (deciding how to decide). Each chapter ends with a list of excellent references that you can use to probe further on techniques. Anyone who is involved in group decision making should own a copy of this book, read it, and refer back to it often.

At the risk of adding one more gushing review to this excellent book - let me say that this book is very good for relatively non-technical folks also. I am working as a manager of a technical team and I used this book to come up on speed on the basics of software architecture. The material layout is very clear and consistent - it helped me to get through the basic concepts quickly and come back for a more detailed reading. The book helped me to ask the relevant questions and focus the team on the right sense of issues.

Only suggestion I have for a subsequent edition is to include one full blown case study.

Having been in the IT world for more than 25 years and studying this topic for many of those years I have found this book to be extremely accessible. I reference it often. I like the way it deals with real business world issues as opposed to on board jet navigation systems etc. I rate it right along with Craig Larman "Applying UML and Patterns".

It is a very thorough and well written book. Authors have introduced idea of perspectives (viewpoints related to cross-cutting concerns) and I totally agree with authors on benefits of using perspectives rather than treating them as viewpoints. My AD of new project is based on viewpoints and perspectives separation suggested by authors.

If you are a software architect or aspire to be one, you should read this book. Rozanski and Woods do an excellent job of explaining the whys and hows of creating software architectures. Their pragmatic, no-nonsense approach makes this book extremely readable. The book is divided into two main sections: an explanation of the viewpoints and perspectives concepts (208 pages) and a catalog of viewpoints and perspectives (195 pages). This makes the book a relatively quick read, but also very useful as a day-to-day reference. If only every software architect would read this book, we might not have as many software quality issues as we have today!

I was impressed with this book's unique perspective of blending the business and technical needs into a single focus, and it continued to maintain the human considerations. It does an excellent job of describing how to support business decisions through architecture at a macro level in a style where "the rubber hits the road."

If you are a systems analyst or a software development manager, this shouldn't be on your book shelf - it should be on your desk for regular reference.

This book is a concise and friendly guide that is great for admins. It proved itself the first time that I had a problem allowing me to quickly find the answer I needed.

This is one of those most have books for any SQL Server DBAs reference library.

Brian Knight covers a LOT of different items and goes into sufficient detail on all topics. Probably the best real world book on SQL Server administration out there. I've worked with SQL Server for over 5 years and have been a senior DBA over a large enterprise SQL Server farm but I still learned a great deal from this book.

This is an excellent book. The coverage of SQL Server is very solid. However, if you plan to purchase the author's newest book, SQL Server 2000 for Experienced DBAs, DO NOT purchase this book. The newer book covers everything this book covers, in addition to the topic of high availability. Owning both books would be completly redundant, a mistake I personally made.

If you're thinking of buying this book, because you've tried everything in Microsoft's online manual "Microsoft SQL Server 7.0 Performance Tuning Guide" and are still having some performance problems, then this book could be your solution.

It helped me solve some of the problems I was having with our productive server and helped me understand some basics a bit better than before. It does not contain everything you need to know, but gives you some ideas how you have to look for further information and what you have to look for.

It contains some good reference material, but not all of the hidden features. As with every book under 1000 pages this is not THE bible for the DBA but is a complementary book that will provide some invaluable information not found elsewhere. This book was well worth the price..

SQL Server 2000 Administration headaches? ... Well if you need a rapid reference on system administrative functions that could not only save your company $$$ on downtime and system availability but improve your response to difficult situations this is a DBA must have. I have purchased more books attempting to get reliable information and tips to make my Administration of SQL Server Database systems robust, reliable, and rapid on response I have finally found the information I needed in "One" book. I would recommend this book for Mid to Senior level Database Administrators and as a guide for training Junior level DBA's to prevent bad habits and teach the proper habits of monitoring, managing and maintaining SQL Server databases overall. Oh and the nice touch is that TIPS: and CAUTION: notices throughout the book educate the creative "out of the box" approach to proper system risk management. I hope Mr. Knight considers sharing his talent with future Administrative Guides !!!

This book has completely smashed every possible expectation I had when I set out to read it.

Let me put it simply. There comes a time in every software developers' life when he contemplates the age old question of, "If I were to be stranded on an island and I could bring only 3 things with me, what would they be?" Well, this would be one of the 3 items. (The other two would be Windows Internals by Russinovich and some other obvious classic like the Windows via C/C++ by Richter, or UNIX Network Programming by Stevens). This book is easily on the same playing field as such classics as those, and its only flaw is that it is not 1,000 pages because when a book like this comes along, you really just don't want it to end. There is so much useful information in here.

The chapter on LPC debugging is worth the price of the book alone, as LPC is completely undocumented and you literally will not find this type of information anywhere else. Every single chapter in this book is filled with gems, and with the plethora of average books being released recently, it really took me by surprise to read such a well thought out book that hits all the right topics in all the right ways.

That being said, it is advanced. Yes, I realize the title says it, but too many books come out with the word Advanced in the title that are merely Intermediate. You need some assembly language, you need to be comfortable with native code, you need to not be frightened at the thought of debugging something for which you have no source code. But for those that meet the pre-requisites, this is a must-have in every sense of the word for the serious developers' bookshelf.

Chapters on debugging heap/stack corruptions are simply invaluable. Worth reading even if you think you know everything about those issues, this book will easily prove you wrong.

A very good hands on book with many gems of knowledge. It walks you through the processes of different debugging techniques with easy to follow screen shots. I definitely recommend this to anyone writing Windows OS dependent code and it is even a very good book to read even if you are a .Net or Java developer on the windows platform. Even if you consider yourself advanced in this area you will still find a few new tricks.

The focus is on debugging using tools other than Visual Studio. There is still a lot of useful information about other tools, but if you want to learn how to debug with the Visual Studio debugger, this is not the book to get.

Have you ever tried to debug a problem in a productive environment? Do you know how hard this can be, especially when you are not allowed to install or use your full Visual Studio environment? Or did you ever try to debug a problem which only happens at the customer's side? This book shows you how to do all of this, and much more. It shows you, for example, how to create and use a memory dump and how to set up and use remote debugging.

And this is a very concentrated book. It covers a very wide area of expertise. It is an indispensable companion for every real world programmer. It explains in detail some of the lesser-known areas of programming infrastructure, like stacks and heaps and the RPC (DCOM) infrastructure, the possible error symptoms and their analysis.

Did you know about the powerful tools in the Debugging Tools for Windows package? This book begins with an introduction to these tools. It shows you how to set up and use them. It introduces you to the user-mode and kernel-mode debuggers, the Global Flags, the Application Verifier and many other tools. All of them are available for free. And you can easily give them to your customers or to the IT department of your productive environment.

Despite its title this book is an easy and entertaining read for a broad audience. While specifically written from the perspective of management of software projects, the book actually addresses management at large. It makes a concise case showing how dangerous and detrimental it is (to the successful outcome of large scale (software) projects that is, defined by the author as a "quality product on time and on budget") to separate technical leadership/management from personnel leadership/management, as so often mandated by many organizations. The "manager-architect," as termed by the author in his book, is key to success. Consequently not everybody can be up for this task, and only few who dare to try will succeed at it, as evidenced by the disconcerting fact that many "top level managers" manage nothing but major budgetary overruns (be they hidden or not), for which they are "held accountable" by society by being hailed as "America's Best Leaders." This book puts an end to such phoniness and provides especially the inexperienced/naive reader with a skill set to reveal/uncover such mismanagement and the individuals responsible.

The book is a true eye opener for aspiring and "want-to-be" managers alike. Also, having posters on "true leadership" pinned to the office wall does not magically inhale the ability of leadership into the office occupant. Leadership is an ability rather than a skill as clarified by the author. It is just like playing an instrument: it only gets you so far if you do not have it in you and practice every day. Chapter 12 "The Impact of Leadership on Software Development" should be read by any manager (aspiring, "want-to-be", or acting alike), and in particular by those who confuse management with suddenly having power over people. Moreover, management does not and should not mean "tenure" along the lines of "now I have made it, now I can relax" or "now I am in power." Rather the "Old Fritz" (Friedrich II, Prussian King) statement, simple yet true, comes to mind: "I am the first servant of the country" ("Ich bin der erste Diener meines Staates"), and serves as a good guide.

The author puts forth an interesting concept for true autonomy founded on the philosophical considerations of the human mind, upon which the AI-(IF-THEN-ELSE)-community will most likely have to choke. In doing so, the author outlines nicely the profound difference between automation and autonomy, two terms, which are often confused, intermixed, or misunderstood, even by so-called experts in the field.

If management is done right, as exemplified/laid out in this book and practiced by its author in an exemplary fashion, managers would rather have to be pitied because of their huge added responsibility for their people/troops and the projects they manage/lead (in that order!). Special attention should be paid throughout the book and in particular throughout Chapter 12 to the "Machiavellian Prince," as this kind of "leader" unfortunately exists (and not in small numbers!), and, while striving only for personal power and gain, causes a lot of damage to otherwise noble causes.

The author of this book has deep insights and wisdom for any level of interface with computer science applications. You simply cannot go wrong for putting your weight down on patterns to follow from someone who has had success in the field. The techniques in this book go beyond basic head knowledge, into the live action of software development where the rubber meets the road. Only an experienced person can give these insights. I am very impressed with the advanced mapping, made simple. This book seems to be written for people who are looking to find answers to every day problems in a rapidly moving computer world, without fear.

Mr. deGyurky gives a great overview of his experience at JPL in organizing and developing large, complex, software systems, and delivering them on schedule, on cost. Mr. deGyurky demonstrated that the most important contribution to software management is that of leadership in life, carries over in software development also.

If you are thinking of becoming a manager of a software development project, you should check this book out, and You will be a step ahead of the game!

The author has given us a framework for conceptualizing, organizing and developing large, complex, software systems, and delivering them on schedule, on cost.

His approach to software development emphasizes two basic ideas. Unique is his application to the development process of the cognitive philosophies of the great Nineteenth Century German cognitive philosophers, principally Schopenhauer, Kant and Hegel, which De Gyurky has studied for years (- in the original Nineteenth Century High German). De Gurky also emphasizes to an extraordinary degree the active role of personal leadership required of the successful software development manager.

Far from being a purely theoretical work, the book is richly illustrated with pungent examples from De Gyurky's near-incredibly varied experience both in the US military as a Special Forces officer commanding a detachment of Montaignards in the mountains of Vietnam, as an action officer at NATO Headquarters, and as the civilian developer of very large military flight-schedule management systems as well as spacecraft software command and control systems.

All the examples are exquisitely pertinent to the software development process. But in addition, four detailed programmatic examples are presented, together with comments, figures and schedules. The author's application of the principles he developed is wholly consistent and unfailingly pertinent, if sometimes challenging, due to the likely unfamiliarity on the part of the typical software engineering reader with the application of the philosophical concepts.

In fact, the single characteristic of the book which may challenge the typical software developer is the accessibility of some of the concepts. Some of the most powerful concepts discussed, e.g., the dialectical process by which an ill-formed idea becomes an object that reflects the meeting of the minds of the design team, are likely to be unfamiliar. However this process has profound implications for the organization of the design team, its management, team-member responsibilities, and on and on. It might have been helpful if the author had expanded on these key concepts, perhaps in context closer to their original use. It would be demanding on the reader, but probably no more so than parts of the book itself.

This unique contribution is recommended to software developers interested in on-time, on-cost development of large software systems, and willing to invest in the intellectual effort required to understand the author's unique contribution. They will be well rewarded.

I have read many books on systems and software development and management principles over the years. The ones that most influenced me were: "More Reliable Software Through Composite Design" by Glen Meyers; "Up the Organization" by Robert Townsend; and "Reengineering the Corporation" by Michael Hammer and James Champy. And of course no system developer's library would be complete without "Managing the Software Process" and other books by Watts Humphry, a giant in our industry. Mr. Szabolcs Michael deGyurky's book will occupy a place along side these on my bookshelf.

In this book, Mr. deGyurky has provided a completely different and refreshing, but no less important, viewpoint on systems development. As different as all the above mentioned books are, the one theme common to all of them is their focus on the "real" problem by differentiating between the truly important and the seemingly important - commonly referred to as separating the wheat from the chaff..

"The Cognitive Dynamics of Computer Science" focuses on strength of character as being indispensable to successful completion of complex systems development projects, which not only satisfy the "real" requirements, but ensure the system is delivered within an agreed to budget and schedule. This book draws on the philosophy of such estimable historical figures as Kant, Hegel and Schopenhauer, among others, in defining the behavioral characteristics of successful leaders and managers. Personal experiences in real world projects by Jet Propulsion Laboratory (JPL) provide a substantive backdrop for Mr. deGyurky's approach to managing systems development.

It is impossible to adequately relay the impact of such a book in so short a review, but I do come away with some points which derive more meaning because of my own experience: 1) Design from the user in, but develop from the inside out, in layers, 2) Don't implement until you have an initial design documented and understood by the development team - expect that to change, 3) Manage change through the Project Implementation Plan (PIP), which is the Project Manager's equivalent to the Software Development Folder, 4) Don't hire staff until you have their tasks well defined (control burn rate and you have controlled your budget), 5) Make sure you understand exactly what your customer wants through constant customer involvement, 6) make your customer's goal, your goal, then incentivize the entire development team to focus on that goal as the highest priority, 7) There shall be no implementation without documented, repeatable process and standards, which should be tailored to the individual project, but at no time should process and standards replace common sense in a dynamically changing development environment, 8) Employ tools and ensure the team is involved in their selection, 9) Ensure the development team is trained in methodology, process, standards, tools and system requirements, and 10) the manager should place the needs of his customer and his team ahead of his personal goals.

All of this is done in concert with the philosophical teachings of our great philosophers, who would encourage strict honesty and ethics in dealing with our customer, subordinates, colleagues, company management, even if it means being fired. Of course, one does not fit all the meaning of a 300-page book into such a short review, and one could easily list another 10 or more points of interest.

I agree with almost everything in this excellent book, but may differ on the role played by Computer Aided Software Engineering (CASE) and Computer Aided Design (CAD) in systems development. Since CASE tools became mature enough to use effectively, I personally selected my tools, then built my process and standards around them. This includes the way I modify process and standards (including DoD) to conform to streamlining development and associated documentation. The CASE tool, when used with discipline can ensure that interface errors are avoided during the design process, as provided through automatic leveling and validation as the system design progresses. Fixed price contracts caused me to gravitate to using the latest tools available and build around them each time.

I am certain that Autonomous Cognitive systems are in our future, but not without application of increasingly sophisticated CASE tools and compilers (Autonomous Cognitive Compilers), which can parse complex combinations of Boolean expressions with many operations per expression to simulate the human thought system in making decisions. Neither can these systems be built without addressing the transducers (sensors), which would connect to and provide stimuli to be interpreted and processed by any autonomous system as the 5 senses (sight, hearing, touch, smell and taste). I look forward to Mr. deGuyrky's next book, which may address this highly complex problem.

I would only close this review with one last comment, directed to JPL. Mr. deGyurky and his team were on the right track with Ada. It is unfortunate that JPL didn't adopt this very highly typed and disciplined high order language as their standard development language. I believe it would have saved more than one failed project. Based on my 40 plus years of developing computer systems, I would humbly suggest that JPL require mandatory use of Ada in all "Class A" development projects.

Planguage is a word and concept that combines Planning and LANGUAGE and is rooted in the author's experience since 1960. The core tenant of Competitive Engineering is that well structured specifications have a dramatic cost reduction over down-stream error correction. The defect prevention process (DPP) is used to clean up early stages specs, or preferably measure defects and motivate lower defect injection, in specifications and the attendant issues instead of relying solely on defect detection andcorrection once actual development has begun. Competitive Engineering provides focus and skills to dramatically increase how productive many of us have been in the past.

The centrality of quality specifications means significant gains for the broadest spectrum of stake-holders who stand to win with the System Of Interest (SOI). Take this specification as an example to clean up:

"The new system will use Foo language running on OS Bar and ensure top industry quality response time on web requests."

People in the field have seen specs like these. Hopefully you aren't writing them. There are what Gilb classifies as "Major defects" in this spec. Which web requests, the front page or all of them pulling from the various databases? Can the old system be incrementally upgraded instead of an entirely new development environment? Why use Foo and Bar if something else gets the job done better, faster, and with less resource utilization? Just how fast is "fast", anyway?

In Competitive Engineering you're told to get measureable quality requirements, record who requested that requirement, and exactly what "success" is defined as. That allows you to go back to the requester with notes such as "If we use OS Baz we'll get a 27% increase in CPU performance" and let them make a decision or escalate to the project funder. You're also encouraged to weed out "design constraints"; at least out of the mandatated and into the labelled area "Design Constraint". Wouldn't it be great if you got a specification that let you design the best you could without technical input from someone that can't use a web-browser?

See if you can understand my re-write of the above spec into Planguage.

Response Time on Front Page of Company Website.

Type: Performance Requirement
Version: 1.2
Status: Draft
Owner: F. Flintstone

Stakeholders: Marketing, Server Support, Corporate Intelligence, ,

Ambition: The front page of the corporate website should respond fast enough to keep the viewer's attention.

Description: Marketing research indicates the typical business website viewer makes an opinion on the website, and thus the company, within 20 seconds. Our corporate site pulls data from three different databases and a sizeable image library, taking an average of 26.87 seconds on a home DSL/Cable modem equivalent network. Marketing advantage can be gained if we can grab viewer attention noticibly faster than our two nearest competitors who average 23.43 and 26.09 seconds, respectively.

Vision: Enough accurate information provided quickly enough to keep the customer on our site.

Scale: Time, in Seconds, to a complete front page load on the equivalent of a 250K network connection.

Past [Front page, 1 Apr 07]: 26.87 seconds

Goal [1 November 07]: 19 seconds <- Marketing Director: BR

Stretch: 15 seconds

Wish: 9 seconds

Design Constraint: Supportability <- Server Support Manager WF Must utilize .

Design Constraint: Security <- Corporate Intelligence BB Must meet .

------------------------ end of spec example --------------------

Probably the only thing that might confuse you about that specification is the use of text within "<...>". Planguage uses that to denote a "fuzzy requirement"; something that is defined but not with the concreteness you'd like. In this example, however, it would be relatively simple to query B. Rubble for the specific guidelines her team seeks to enforce. The use of fuzzy requirements also allows for change over time; more OS versions may become supported while others are obsolete.

When I read part of an electronic copy of the text I had a problem. My antiquated home printer could not print it and if I used the work printer I view the output as a possession of my employer. The book is written as part instruction, part reference manual; I bought my own copy because I know I'm going to use it for the next few years and several employers.

This is one the books which has caused a great impression on me. It helps to get away from high-level, gut-feeling, fuzzy goals and descriptions to very concrete targets, unambiguous requirements and rational decisions. This strikes a chord at the heart of systems design and architecture, which consists in maximizing a set of business goals with limited resources (time, budget, personnel). I highly recommend it.

Building software systems is not easy, this book can help you to do a better job.

In a period where the trend is to follow agile approaches with condensed guidance (see the 12 principles of the Agile Manifesto for instance), it could seem strange to publish a book on software development with more than 500 dense pages. You should however not be frightened by this book. Beneath the size and the structured form lies an approach based on practical experience that incorporates change and flexibility without abandoning the quest for precision and delivering value.

The main concept of Competitive Engineering is Planguage, a word created mixing plan and language. Communication is the basis for working together. This is why Tom Gilb emphasises first the creation of a common vocabulary. He states that his glossary could be considered as the best contribution of this book. Beneath the definition of a common language, for me the "hidden agenda" of the book is to help us to think... further. The common language is only a tool that helps us express our thoughts more precisely and completely.

Fortunately for us, Tom Gilb didn't only write a dictionary of system engineering. A large part of the book is devoted to the activities of system engineering and project management. Based on Planguage, Gilb gives us a framework to elicit clearer requirements. He emphasises a measurable vision ("bad numbers beat good words") and presents tools to achieve this objective. He also helps us separate requirements from design. He devotes an entire chapter to quality control. Finally, there is a presentation of the techniques of evolutionary project management that supports incremental development based on the priority and impact techniques described in previous parts of the book.

In every chapter you will find examples and case studies that help to visualise how the concepts translate into practice. There is also an "additional ideas" part that presents material for further thinking. Beneath the seriousness of the topic, Gilb also manage to place some lighter parts and you will find how to compare seriously apples with oranges.

At the end, your realise that you have a book where process is not opposed to people, structure is not opposed to flexibility, precision is not opposed to allowing change, documentation is not opposed to active refinement, Gilb's proposed solution is not opposed to customisation for your needs. It is just a book that gives you new inspiration to deliver better software solutions to your customer.

If you are interested in software process improvement, you can read this book from the beginning and find practical material to examine your current practices with a different vision. If you are a lonesome project manager or developer, you could begin by just using the index to get Gilb's view on your current activity or problem. Be cautious, because there are many chances that you will be tempted to read more material ;o)

After reading this book, I browsed again my old copy of "Principles of Software Engineering" that I bought when it was published in 1988. I saw that many ideas from "Competitive Engineering" were already presented in this book. Tom Gilb just applied to his ideas the same concepts he proposes for system engineering. He refined, expanded and structured them to get a better product. The printing industry has just prevented evolutionary delivery, but you can bet that he will find a way to include this in the future.

My interest in the topic of competitive engineering (CE) was piqued several years ago when I heard very favorable comments about Tom Gilb's tutorial on that subject at the INCOSE 2002 Symposium in Las Vegas.

The book's subtitle is "A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage". The term "Planguage" is central to an understanding of the book. Planguage, which is derived from a union of "plan" and "language", is the methodology for implementing CE. Much of the book is devoted to describing the generalized processes, rules, and vocabulary of Planguage. Tom notes, "Planguage should be viewed as a powerful way to develop and implement strategies that will help your projects to deliver the required competitive results." Fundamentally, the book presents a new take on best practices in systems engineering and management.

The book is useful on several levels. For organizations without a formal or documented process, tailoring of Planguage would jump start the process at a high level of maturity. For organizations that have achieved CMMI level 3 status, Planguage by itself is not as useful. However, many of the ideas of CE-the Planguage methods-are worth considering for enhancement of existing organizational processes. Tom states that CE is "about technological management, risk control, and breakthrough improvement in complex business systems, projects, and processes." CE is a believable approach for delivering complex projects on time and within budget.

The book passed my value-added test, when I realized that I was photocopying several pages for future reference, to be part of my "toolkit" of helpful tips and techniques. I particularly enjoyed reading the 10 often witty, summary principles in each chapter. Two examples are:

* The Principle of `Storage of Wisdom': "If your people are not all experienced or geniuses, You need to store their hard-earned wisdom in your defined process. Capture wisdom for reuse, Fail to write it, that's abuse!"

* The Principle of `The early bird catches the worm': "Your customers will be happier with an early long-term stream of their priority improvements, than years of promises, culminating in late disaster."

About 30% of the book is the Planguage Concept Glossary, which Tom views as a central contribution of the book. I focused my attention on the other, more interesting, parts of the book, which describe the main CE/Planguage methods of Requirement Specification (RS), Design Engineering (DE), Impact Estimation (IE), Specification Quality Control (SQC), and Evolutionary Project Management (EVO, also known as Evo). RS describes an approach for identifying all types of requirements while avoiding ambiguity and also planning for change. Functional and performance requirements are distinguished. DE deals with identifying, choosing, and prioritizing the order in which design ideas are implemented and delivered. In conjunction with Evo, DE selects the design ideas most likely to provide a significant benefit for early delivery.

SQC is an eminently practical approach for evaluating the quality of any technical document via sampling measurements. An hour of SQC early in a project can save almost 10 hours of rework. SQC also provides a means to assess the success of process improvement efforts. IE provides a realistic method for evaluating-in quantitative terms-the effectiveness of designs in meeting both the requirements, especially critical performance attributes, and the resource budgets.

Evo focuses on early, frequent delivery of project results via a series of high-value, small evolutionary steps. An ideal Evo approach would divide the project into a series of cycles. Each cycle would consume 2-5% of the total financial budget and 2-5% of the total project time-while delivering some measurable, required results to the stakeholders. The next cycle is selected to deliver the best stakeholder value for its cost (highest ratio of value to cost, or highest ratio of performance to cost). Although an ideal approach can't always be realized, Tom provides some convincing examples to argue that there is always a solution to making a project evolutionary (small steps with critical deliveries first).

Perseverance pays off with Competitive Engineering. The book is not a quick read, which Tom acknowledges. You have to carefully study some of the pages to understand the concepts being presented. The reward occurs when you glean the nuggets of wisdom from the numerous practical examples, case studies, and Planguage examples. Tom's way of presenting the CE concepts makes the book a useful addition to the systems engineer's library.