5 comments about The Computer and the Brain: Second Edition (Mrs. Hepsa Ely Silliman Memorial Lectures).

1. A book for a limited audience. You have got to be interested in some really seminal, currently unresolved issues of how the great invention of the ALU (arithmetic logic unit) still employed in every computer built to the present day, was a compromise effort by this genius. His thought was to model the human brain, and the ALU succeeded in modeling just a small part, but he was totally frustrated and unsatisfied by the result--for good reason. He points out that the very language of the human brain has not yet been discovered--the orders of magnitude by which its process and results exceed the merely digital high speed comparator we call a computer (my apologies to Bill Gates!) clearly demonstrate the existence of a logic and a mathematics, the simplest rules of which as yet defy all our efforts to understand its workings, while we experience its results every time we think. Depth of logical levels, and depth of arithmetic levels necessary to achieve the requisite results we obtain from our Crays and our PCs are scorned by the human brain in a radical simplicity as yet undiscovered (not in that it does it, but in how it does it: therefore he postulates the existence of a radically, essentially different math and logic inherent in its workings). He lays out the discoveries of Turing, McCullough and Weiner in a brilliant tour de force of known (1955)neurological and cybernetic discoveries, and how they charted his course in creating the ALU. He compares analog and digital and mixed models of computing but (in my opinion) oversimplifies the digital aspect of thinking and memory, deeming them to be the route used by the human brain in performing its unruffled magic. He closes by posing two questions that express the wonderment faced by a high level intelligence when accosted by the facts he was unable to wrap mental arms around: 1)"what essential inferences about the arithmetical and logical structure of the computing machine that the nervous system represents can be drawn from these ...conflicting observations? and 2)what are the logics and mathematics in the central nervous system [that must be]structurally *essentially* different from those languages to which our common experience refers? His fellow researcher, Warren McCullough similarly closed out his life and research by repeating a question that plagued him all his life: What is a number, that a man can know it, and a man that he can know a number?

   This is a great book that pushed the limits of his time; his swan song, to be delivered as the Yale Silliman lecture, but never was, due to Von Neumann's tragic untimely death in his early fifties.




2. Perhaps the most famous and often quoted line in this remarkable book appears on page 39, where von Neumann declares that "The most immediate observation regarding the nervous system is that its functioning is prima facie digital."

   The "prima facie" modifier is commonly taken to mean von Neumann saw the brain as "obviously digital," or "patently digital," and that it therefore must resemble a digital computer. But as you read the rest of the book, you quickly discover that this is not what John von Neumann intended. Von Neumann uses words cautiously and precisely, and to him, "Prima facie" means exactly what it says: "on its face."

   In 1956, the brain appeared digital. But von Neumann thought this impression might be superficial. He thought that deeper biological investigation might well demonstrate that the nervous system is not, in fact, digital, or not completely digital. He believed it might work in some more sophisticated way, and suggests that perhaps some intermediate signaling mechanism, a hybrid between analog and digital, might be at work in the brain. For this and other reasons he actively resisted labeling the brain as a digital computer.

   In the mid 90s, evidence began to appear that von Neumann was probably right to reserve his judgment. These curious new results show that a single nerve impulse is somehow able to convey information to the brain. This signal seems distinctly un-digital. A number of theories have popped up, some attempting to explain this whopping new mystery, others attempting to explain it away. But its impact on neurophysiology, and on conventional computer models of the brain, is pretty shocking. Not to say, devastating. (See Spikes, by Rieke et al, for a readable account of this story.) When the smoke clears, it would not be surprising if people go all the way back to John von Neumann, looking for traction, fresh starting points, and for von Neumann's wonderfully broad sense of what is possible in neurobiology - a sense we have evidently lost to progress in the years since he wrote this splendid essay.

   Von Neumann did not include in this book his interesting views on the nervous system of the eye. He was an early adopter of visual memory systems in digital computers, and he was evidently intrigued by the way the retinal cells of the eye are arranged to look backward, that is, toward the screen of the back wall of the eye. Possibly he thought the retinal cells saw back there a thin film diffraction pattern. You can find his interest in the nervous system of the eye remarked in his brother Nicholas Vonneumann's book, John von Neumann as seen by his Brother, and this reminiscence is also paraphrased in Poundstone's Prisoner's Dilemma. Finally, some of the worldly story of von Neumann, his digital computers, and their role in the creation of the hydrogen bomb can be found in MaCrae's biography.




3. Perhaps the most famous and often quoted line in this remarkable book appears at the beginning of Part II, where von Neumann declares that "The most immediate observation regarding the nervous system is that its functioning is prima facie digital."

   The "prima facie" modifier is commonly taken to mean von Neumann saw the brain as "obviously digital," or "patently digital," and that it therefore must resemble a digital computer. But as you read the rest of the book, you quickly discover that this is not what John von Neumann intended. Von Neumann uses words cautiously and precisely, and to him, "Prima facie" means exactly what it says: "on its face."

   In 1956, the brain appeared digital. But von Neumann thought this impression might be superficial. He thought that deeper biological investigation might well demonstrate that the nervous system is not, in fact, digital, or not completely digital. He believed it might work in some more sophisticated way, and suggests that perhaps some intermediate signaling mechanism, a hybrid between analog and digital, might be at work in the brain. For this and other reasons he actively resisted labeling the brain as a digital computer.

   In the mid 90s, evidence began to appear that von Neumann was probably right to reserve his judgment. These curious new results show that a single nerve impulse is somehow able to convey information to the brain. This is distinctly un-digital. A number of theories have popped up, some attempting to explain this whopping new mystery, others attempting to explain it away. But its impact on neurophysiology, and on conventional computer models of the brain, is pretty shocking. Not to say, devastating. (See Spikes, by Rieke et al, for a readable account of this story.) When the smoke clears, it would not be surprising if people go all the way back to John von Neumann, looking for traction, fresh starting points, and for von Neumann's wonderfully broad sense of what is possible in neurobiology - a sense of possibilities we have evidently lost in the years since he wrote this splendid essay. He is eloquent on the problem of selecting a memory "organ," and evidently thought the worst choice would be a neuron.

   Von Neumann did not include in this book his interesting views on the nervous system of the eye. He was an early adopter of visual memory systems in digital computers, and he was evidently intrigued by the way the retinal cells of the eye are arranged to look backward, that is, toward the screen of the back wall of the eye. Possibly he thought the retinal cells saw back there a thin film diffraction pattern. You can find his interest in the nervous system of the eye remarked in his brother Nicholas Vonneumann's book, John von Neumann as seen by his Brother, and this reminiscence is also paraphrased in Poundstone's Prisoner's Dilemma. Finally, some of the worldly story of von Neumann, his digital computers, and their role in the creation of the hydrogen bomb can be found in MaCrae's biography.




4. Von Neumann was one of the most celebrated and prolific mathematicians of the 20'th century; his contributions were legion, and always bore unmistakable creativity and elegance. "The Computer and the Brain" is a record of a lecture series that von Neumann delivered at Yale University in 1957. In these lectures, von Neumann set out to explore connections between computing hardware and their biological counterparts; brains. Von Neumann compared neurons with physical computing elements in terms of size, speed, heat dissipation, capacity, etc., in an attempt to discover what, if anything, could be said to unite them or to set them apart. He drew from what had been learned in designing computer instructions and memories in an attempt to glean some insight into what the brain might be doing. Ever the consummate mathematician, von Neumann was guarded in his statements, never over-reaching or confusing speculation with fact.

   The ideas contained in these lectures will come as no great surprise to most scientists today; indeed, I would expect most to simply nod in agreement at most of von Neumann's observations. For example, von Neumann notes that neurons are essentially digital in that they have an all-or-nothing activation energy. However, it is interesting to see how seriously he pursues the idea that the brain may rely upon a mixture of analog and digital encodings; he took absolutely nothing for granted, and may well have been vastly ahead of his time.

   Although von Neumann's many references to vacuum tubes and differential analyzers may seem archaic today, his central points remain essentially intact. I'm certain that von Neumann would have felt somewhat vindicated by the explosive advances in semiconductor devices (in both digital and analog incarnations), as well as in machine learning and neurobiology. One can perhaps view von Neumann's lectures as the first glimmerings of what would eventually become fruitful exchanges between computer science and various biological disciplines.

   If you are looking for a discussion that will give you some insight into artificial intelligence, neural networks, or brain physiology, then I'm afraid you will likely be disappointed with this book. While many of von Neumann's observations may have been controversial at the time, they have for the most part moved quietly into the collective consciousness of scientists. However, if you have interest in either the historical development of these ideas, or in seeing how one of the preeminent minds of the 20'th century approached this vexing new problem, then it will be worth your time.

   What I most enjoyed about this book is von Neumann's methodical and exceedingly cautious approach, coupled with his occasional willingness to speculate. As the vast majority of von Neumann's writings are accessible only to a very small audience, such as his enormously influential treatises on quantum mechanics, geometry, and game theory, and his pioneering work in areas such as functional analysis and operator theory, this little book is perhaps unique in that it lets you in on the ground floor.




5. After the quick read that it was this morning I am left uncertain as to exactly how I feel about this book. On the positive side even though one does get the feeling that The Computer and the Brain is slightly dated (1958) it has held up remarkably well despite the extreme rate of technological development. On the negative side though it is a bad sign when the most enjoyable part of a book is the foreword.
   
   The cover of the book basically tells the whole story, apples and oranges- for while as von Neumann recognizes that "the most immediate observation regarding the nervous system is that its functioning is prima facie digital" the connection between them is not as strong as a first glance might suggest.
   
   There doesn't seem to be too much that a study of one can teach us about the other but maybe finding out that lack of an underling connection is just as useful as finding such a connection. While this book is a fairly good recitation of the facts (at least as they were known in 1958) I can't say there is really much here to recommend it to the casual reader- think that only as a reference work can this book gain high praise.

5 comments about Unit Test Frameworks.

1. I have put off writing a review of this book because I had very mixed feelings. On the plus side, it is a very clear concise guide to unit testing - a great introduction.
   
   On the negative side, I figured that any decent programmer already knows what's covered here. Even those who don't write unit tests (bad programmer, bad) knows what they are and how to do it.
   
   Then I was stuck on how to unit test in a particular case and the author email me - look on page 37. And there it was.
   
   So, if you are learning to program - GET THIS BOOK. No one will hire you unless you know this. If you're an experienced programmer, it can still teach you a thing or two.
   
   - dave thielen
   
   ps - the author is a friend of mine and that did cause me to round up my 4.5 rating.



2. This is a very solid, no-nonsense introduction to unit test framework.
   
   For a 200 page book, this one is packed with carefully chosen information, detailed enough for new comers to start unit testing, useful enough for a frequently-visited reference, and at the same time concise enough for anyone to get an overview of the unit test landscape.



3. I have been using JUnit for unit testing on Java for quite a while and I have also been exposed to other testing frameworks, but had never looked under the hood is such detail as Paul does in this book.
   
   He starts with a good overview of what a unit test framework and then takes us to a very nice tutorial on building your own unit test framework from scratch. This exercise is very well documented and you learn the basic principles behind a unit test framework while building a simple application and the unit tests required to test it.
   
   After laying out the foundation, he goes on to explain in more detail how to write unit tests, how to use assertions, how to deal and test exceptions and expected errors, how to test protected behavior, how to organize your project for testing and using more advanced techniques like mock objects and performance testing.
   
   He also includes a chapter that deals with testing GUIs (Graphical User Interfaces) which is a challenging task, but he offers good ideas for doing test driven development for a GUI to the application that we have been building during the previous chapters.
   
   After all the basic concepts have been covered, the next chapters are dedicated to the most important (or more popular) unit test frameworks which are JUnit for Java, CppUnit for C++, NUnit for C# on .NET, PyUnit for Python and XMLUnit for XML documents. It is interesting to note that throughout the book the author uses the same application for the example code, so that we can compare the actual implementation of the tests using the different frameworks.
   
   In the appendices, there is a C++ version of the simple Java framework that was built on chapter 2 and there are also summaries of the class reference documentation for JUnit and CppUnit.
   
   Overall I think it is a very solid book with good examples and very concise content. Even though it doesn't cover all the unit test frameworks that exist today, I think it covers the most important ones, but the real gem is on the in-depth analysis of what makes a unit test framework.
   
   If you are already familiar with one or more unit test frameworks, this book will give you a deeper understanding of them, and if you are still programming without writing unit tests... shame on you ;-)... buy this book and learn how simple it is to have a very good unit testing framework, no matter what language you use.



4. I had used JUnit for several years before picking up this book and I like to think that I know the tool pretty well. So why did I decide to read this book? I read this book because I thought that might help me venture a bit outside my familiar JUnit turf and into doing test-first programming with languages other than Java. The short version? A very nice introduction to all the included xUnit ports. The long version? Read on.
   
   The first four chapters are general introduction to the topic of unit testing (and to some degree, test-driven development). I was prepared to do a quick scan through them all but ended up reading chapters 3 (xUnit architecture) and 4 (writing unit tests) almost word to word-the topic was mostly familiar but the authors solid writing kind of kept me going.
   
   The first two chapters didn't pique my interest that much, perhaps because I had already seen people develop a unit test framework from scratch as an introduction to the domain.
   
   The real meat of the book that I was looking forward to was in chapters 7 through 9, the introductions to CppUnit, NUnit, PyUnit-which were mostly new to me although I had done very little fooling around with them before. I wasn't disappointed. The author managed to put together a pretty good set of tutorials for these frameworks. Obviously the same information is available online but I still prefer reading a treekiller rather than a printout of a web page.
   
   The not so bright spots in the book, in my opinion, were the chapters on unit testing a Swing GUI and on XMLUnit. Not that they were in anyway badly written. I just felt like they didn't belong. I would've personally swapped in a couple of additional xUnit ports instead (Ruby and PHP, for example).
   
   This is definitely not a book you'll carry with you from project to project. There's approximately 100 pages of substance split among half a dozen topics so none of them gets covered in detail. The rest, almost 100 pages of the book is what I'd classify as "nice to have"-I don't mind having that material in the book but I also wouldn't have minded if they'd left them out.
   
   To summarize, if you'd like to get an idea of how the unit testing frameworks on different platforms/languages differ and what they have in common, this is as good an introduction to them as any and well written in all dimensions. However, you might be disappointed if you're looking for a more long-lasting companion.



5. [reviewed by XPSD member Paul Hamill]
   
   Unit testing and test-driven development (TDD) is a skill that has been desperately lacking on many of the projects I have been involved with over the last few years. I have tried reading books by Kent Beck and others on this subject, but I have always had trouble getting to the next level of applying the skills to "real" problems. This book does not take the approach of claiming to teach you how to be a great test-driven developer, instead it is a survey of the unit test tools available for many environments today and along the way explains the fundamentals of unit testing and TDD.
   
   If you have read other books on TDD, you may find much of this book a review, however there are many explanations of how some of these tools would be used in actual projects which I found valuable. The discussion of mock objects is a good one which explained some details about how to use mock objects in practice that I didn't understand in reading other sources on the subject. In addition, several tools I was unaware of were discussed that I am interested in looking into for making TDD easier to do. For example, XMLUnit and NUnitForms are 2 tools that would seem to make testing a data-driven GUI application much more manageable.
   
   I would recommend this book for anyone who has an interest in unit testing or test driven development and wants to know what tools are available to do this. Also, this book would be invaluable if you intend to write your own xUnit framework for a language.

5 comments about Software Project Secrets: Why Software Projects Fail (Expert's Voice).

1. George Stepanek's Software Project Secrets: Why Software Projects Fail surveys the reasons why software projects fail: most commonly conflicts between software developers and project manager goals. It's the first to analyze how project management's goals conflict with software development - and to provide a solution to the time and budget goals of managers and the accuracy of software developers.



2. I work for a software company as a Senior Technical Writer, so when I reviewed this book, I expected it to hit close to home. It did.
   
   In the second of two software development firms I have worked with, I realized that the issues which George Stepanek brings out in his book were the same challenges for each company. All parties involved had their own agendas but none of them followed the same methodologies for getting things done, or they found their methodologies did not exact work with Software Development projects.
   
   This is especially true when it comes between the Software Developers and the Project Managers. The Project Managers tend to see only their schedules and not the challenges of the Developers, such as time, code requirements and adequate staffing. I think sometimes the Developers live, eat and sleep at the office to try to get the software to GA (General Availability).
   
   At the end of a development project, many times you look back and try to figure out what went wrong, or what steps to avoid for next time. I think it is wonderful that Stepanek details the key factors which cause a project to fail. Many Project Managers look at the specifics of a software development project only to find they can't quite figure out the difference between this type of project and the others. Fortunately, for the reader the author identifies twelve facts that make software development so different from other projects. With these facts, clearly in hand, Project Managers and Developers can come closer together to make the project a success. Unique to this book as well, Stepanek also identifies ten wrong assumptions (in his analysis of the "Project Management Body of Knowledge") that are made by managers and how to avoid them.
   
   Stepanek also takes a look at three modern project management methods. This is a topic that many books on Software Development and Project Management fail to address. He details what parts of each methodology works to solve some of the issues of software development projects. Almost more importantly, Stepanek identifies the areas in which these tried-and-true methodologies fail to solve the unique problems of software development projects.
   
   Going one step further, the author discusses seven different techniques that can be used by Project Managers to ensure that the projects come in on time and on budget. This should be music to Project Managers' ears!
   
   One thing I do like is the illustration of a point or an example. Stepanek includes a case study at the end of the book which shows what challenges can appear and how to cope with them successfully.
   
   This book should be required reading and a great supplement for the Project Managers, Product Managers, Software Developers and even customer who have been trained to use the methodologies commonly used in the industry, but still have project that fail or are difficult to manage to completion.



3. If you've been or had been working on a software project, you will know what George is talking about. Small of big, a software project never fail to challenge you with every-growing requirements (so the complexity), unexpected obstacles, and never-enough-time. The book well analyses the nature of software project and provides a good insight of the real challenges/issues we face when working on a software project, so to help us deal with them better. Very useful to read.



4. The book compares software project management from a number of "agile development" perspectives to the PMI model for project management. The book illustrates assumption made in the PMI methodology, and provides a counter point or rebuttal to those assumptions. Thus the book suggests the PMI model is not entirely applicable for software project management. While this book challenges some of the PMI methods, it provides alternative approaches to achieving project success. I liked the book, and appreciated the examples, even when I did not fully agree with some of the assertions.



5. When I first read this book about two years ago, I wasn't that impressed. I thought author George Stepanek spent too much time explaining things that seemed obvious, and was indecisive in the recommendations he made. Having a few more years experience under my belt, I have a better sense for author was getting at and more of an appreciation for the book.
   
   The first section of the book runs down 12 challenges of software development that make it unique from a project management perspective. This section is mostly valuable for novices, but objective enough to be worth reading for veterans as well. The author makes a particulary good point in that software development is research and that you're inevitably doing something new each time. However I find the real value in this section is that it allows the reader to objectively judge the processes introduced later in the book.
   
   The approaches that Stepanek advocates are all clearly in the Agile realm. The three methodologies discussed are Crystal, Rational Unified Process, and Extreme Programming. This is probably the only book I've ever read on software development process that doesn't advocate one methodology over another. Stepanek recognizes that different approaches apply to different situations, and this is one of the book's biggest strengths. If you're unfamiliar with any of these three approaches, this is a good book to start with.
   
   Stepanek brings things together with a pair of case studies, which he uses to contrast the traditional waterfall approach to the more modern Agile methodologies. The Agile case study is of more interest; Stepanek blends techniques from different methodologies and shows how they can be used in conjunction to solve different problems. The case study is somewhat limited in scope, but it provides concrete examples of using the techniques described earlier in the book. By blending techniques from different methodologies, the author avoids a "one size fits all" recommendation, which I've found other books prone to.
   
   The one thing to be aware of when reading this book is that its content is better suited to developing internal applications rather than external production applications. The thinking is more geared toward an environment where budget and schedule are more important than things like user experience and performance. If you're contributing to an internal software project in any role, I'd recommend giving this book a read.

1 comments about How to Manage the IT Helpdesk - A Guide for User Support and Call Center Managers (Computer Weekly Professional).

1. I was incharge of starting up a new help desk. This book was definitely the wrong book for that. I thought it was going to be more basic, foundational level instructions.
   
   I guess it was not what I was looking for...

5 comments about Excel 2002 Power Programming with VBA.

1. This book can be included in the handy tool category, a "must have" for non-programmers who want to give their Excel applications a professional look as well as get the most out of Excel without wasting much time and effort. Word of caution, a bit of familiarity with visual basic as a language and the controls etc. will be very helpful in using this book. Codes in the CD are very helpful. It is written by a practicing professional from usage point of view hence a very easy reading book and not heavy on the jargons of object oriented programming etc. I learned a lot of useful tricks after going through the book.



2. Outstanding reference and how to manual for Excel macro programming. A must have for anyone who has ambitions of writing their own programs for Excel. John's clear, organized, and comprehensible writing style allows even a novice programmer to immediately begin to write Excel macros that really do something, and do something useful. His book is chock full of useful code examples. Get two copies. It is that good.



3. This is a great manual for those who, at a minimum, have a limited knowledge of Visual Basic and a limited working knowledge of Excel. If you don't consider yourself an expert then this is the book for you!

   I've taught myself multiple computer languages (English is my natural language but that doesn't really matter now, does it?) and am very familiar with Excel -- but not so much on the programming side of things. As far as being a VB programmer, well, about two or three years ago I taught myself VB 5.0 and then never ended up needing to use it. The first time I used this book was to help me with a VB module in a customers Excel workbook. There was even an example in this book about using the Windows API to get the window to search for a directory which I was able to easily incorporate into the code. I then started reading through the chapters and just kept on learning more and more! When working on a project I can easily find a relevant chapter/section that pertains to what I'm doing or need and solve my problem!

   He clearly explains his code and if the example is a code snipet. The included CD contains his examples and other files which I find very helpful, especially when I don't want to type in everything myself :-)

   If you even *think* this may be a candidate for your library then stop thinking and just get it!




4. This book sucks! Its just a little better than the help file included in with Excel. All he does is put it in a diffrent order. I was expecting small excercises where I could put my new skills all together, but there is none. So you read the whole book, remember as much as you can, and go off and try to mix and match hundreds of commands... buy another one.



5. This book is oriented for those with basic knowledges of Excel and some general understanding of Visual Basic (Visual Basic 6 not Visual Basic .NET). However, the examples are simple, sequential and conductive for constructing basic applications even if you have never used Visual Basic before.
   
   Let the Author, Mr. John Walkenback, take you through the first 7 Chapters, type in the examples as you go, and you will rip the benefits.

1 comments about Rapid Prototyping of Digital Systems.

1. This is a good text for beginners and slight intermediate users of VHDL. The text specifies the Altera UP1 board (which was the board I used as I atttended my EE program). I discovered this text a little late...when I have graduated and am now using VHDL on the job for CPLD programming. It is a good text for familiarizing with VHDL constucts. Examples are very good compared to the Student Guide to VHDL by Peter Ashenden. If you wish to learn VHDL, My suggestions are to get this text and either of the following:

   VHDL for PROGRAMMABLE LOGIC by Kevin Skahill

   Digital Design and Modeling with VHDL by K.C. Chang

   With a solid background in digital logic, these text will provide you an excellent background in digital design. Good luck.

1 comments about Ontologies for Software Engineering and Software Technology.

1. This book is an excelent way to introduce yourself to a new area about conceptual understanding by using Ontologies as a tool.

5 comments about Software Engineering: Theory and Practice (2nd Edition).

1. This book contains basic information and does not really elaborate beyond that premise. It's not bad but if you are looking for more detail and a little more substance, look for a different book. However, I really did not mind it for a start.



2. This is an excellent reference guide/course book that outlines the processes and issues involved in Software Engineering. The book offers practical examples and discusses "real world" issues. The book has a great website reference as well. Highly recommended.



3. If you HAVE to read this book, you'll know what I mean. The first time I read this book, I hated it... Boring, and one reviewer is right, it covers EVERYTHING under the sun about S/E. Now, after about two years or so, I keep finding myself refering to this book over and over again. I am liking more now that I see how and where to use the topics that it talks about. 4 star, b/c this book could have been written better. First time around was very boring.



4. This book is not worth buying for the following reasons:

   1) The book fails to explain the concepts clearly.
   2) It is rather confusing and boring; the chapters on important concepts are not clearly laid out. It seems the author hasn't given sufficient thoughts to come up with a better work.
   3) The book is full of grammatical mistakes.
   4) It total, it is complete waste of money in my view. There are many other good ones out there in the market on Software Engineering.

   Thanks,

   A Software Professional




5. when you're exposed to faulty education check out this book! this book will teach you from top to bottom what needs to be done...in theory. Moreover, it has sample cases and lots of procedures written by the authors themselves. For those majoring in Software engineering this is a must have!

5 comments about Managing Iterative Software Development Projects (Addison-Wesley Object Technology Series).

1. Iterative Projects are a challenge to plan. They require additional attention to planning and re-planning that traditional projects 'do' but not in forced regular intervals - iterations. This is a solid reference overview of the processes, templates, roles, etc.
   
   Some day... a reference will exist with more details on what was actually planned in iterations of a real project. Address the reality versus the concept.



2. The book appears to be a well written text about doing RUP iteratively. Unfortunately, I am not doing RUP or UP. The editorial review on Amazon quoted from the back cover that it would be appropriate for agile methodologies and not just RUP. While that may be the case for some chapters, for a significant portion of the book, I do not believe it is so. We are implementing Scrum and this book is not the best source to help me with that. It is too heavy and UP specific. I will be returning the book. Don't be turned off from the book if you are doing RUP since it may be for you.



3. Overall I thought this was a very good book for learning about how Iterative Development projects are supposed to work, what the advantages are and why a company might want to use this sort of methodology. The authors did a nice job of avoiding too much methodology jargon as well. Sometimes it seems these books are written only to be read by other methodology academicians, but that wasn't the case here.
   
   I have since shared this book with several other people in my company, including one not even in IT, and they have also found it helpful. So if you are also facing challenges in educating your broader company about how agile development techniques should work, this might be a good place to start.
   
   On the other hand, it is quite long and wordy. Most people will not have the patience to wade all the way through this book, so before I shared it, I went through it with a hilighter and told my people to just read the yellow parts. :-)
   
   My only other beef with the book was that it seemed entirely targeted at internal projects, or for software where the users were all internal. Nowadays that is almost anachronistic. My teams mostly work on web development either for B2B users or for the general public (B2C), which means that statements like "make sure your requirements are reviewed by the business" are of limited value. Our business is our clients and their consumers. If you are working on public web apps, just keep in mind that whenever these authors say "business," they mean "your web consumers" and you should be fine.



4. As agile software development approaches are more and more adopted in software development organizations, the title of this book from Kurt Bittner and Ian Spence seems to be right on the target. The book contains two major parts. The first gives an overview of iterative project management. It defines the concepts, discuss controlling and gives tips to assess your readiness for iterative project management. The second is a more detailed walk-through to the planning and management of iterations at different levels. It provides also information on how to assess the results of iterations, discuss the relation between iterative project management and project scales. The last chapter is dedicated to the information needed to start your first iterative project. Finally, appendices provide material on use case development (the topic of a former book from the same authors), templates, checklists and an example of 50 pages.
   
   The process behind the book is widely based on the RUP approach; thus practitioners of a "pure" agile approach could be disoriented by the content. However, this book contains very valuable and pragmatic material about managing iterative projects that could be used in any iterative context. It will also provide good transition information towards an iterative process for project managers that operate in a more traditional organization. With 600 pages, it is a not an easy book that is quickly digested. It will nevertheless helps you to improve you grasp on iterative project management, whether you read the book sequentially or you pick sections according to your current project management questions.



5. I am moving from iterative development to iterative project management. This book is really wonderful and explains in detail the processes, the risks, deliverables. It will help anybody who wants to think "iterative" development.
   
   BTW, it will also help you talk to dinosaurs and explain your approach to project management. A big help.

2 comments about SVG Programming: The Graphical Web.

1. Finally an SVG Bible for the Web. I have worked with SVG for just under 2 years and had to learn SVG from the W3C documents and lots of "experiments". I have only reviewed half of this book so far and found a wealth of knowledge on using SVG on the Web. It's examples are solid and well organized.

   This book can be used by the novice and the experienced to add the coolest vector graphics to their Website. This book is well balanced for all levels. It has earned a well respected slot next to my computer...




2. This book is head and shoulders above the Eissenberg book (O'Reilly). Kurt Cagle is a serious developer, and the book shows it, with advanced examples that explore all aspects of programming. It would have been nice to have a .zip file that had all the examples in it, but that's a minor nit.