5 comments about Return on Software: Maximizing the Return on Your Software Investment.

1. How I was introduced to this book:
   About nine months before this book was published I was researching the return on investment of software projects. While doing my research, I was introduced to Steve Tockey who asked if I might be interested in reviewing his book.
   
   My background:
   For almost 10 years I've worked in the software and consulting industry. Currently, I work at one of the leading CRM software companies worldwide where I spent three years advising customers on how they can get the most out of their investment in our software. At the time of my research, it was imperative that our division understood how software investments are impacted by certain business decisions and related financial considerations. Today, I am responsible for planning, implementing, and measuring the outcomes of investments and projects within our marketing organization.
   
   Comments on the book:
   This book does an excellent job covering the financial aspects of investing in software systems (or really any investment) as well as covering decision-making and risk management techniques. If your career path includes the development of any business case for software systems, this book explains many of the concepts you will have to use. While the introductory portions of the book explain how financial principles generally apply to software, the book goes far beyond an introduction - honestly, it's depth in content will give it a home on my bookshelf as a trusted reference for years to come. Besides clear explanations and good fundamental examples, the accompanying self-study questions, website, and tools will help readers truly understand and use what is being taught.
   
   If you are familiar with Steve McConnell's books on software, you will not be disappointed with this one (as Steve Tockey works at Construx Software).



2. There are hundreds of books on topics relevant to various aspects of software engineering. However, when we analyze what went wrong with so many of our large practical software projects, one of the leading culprits is a misunderstanding of the business, economic and financial aspects of the projects. Where are the books and courses to help us with this major problem?
   University engineering programs often have a course such as Fundamentals of Engineering Economy. What Steve Tockey has done with his book is to apply these general engineering economics topics specifically to the field of Software Engineering and set a standard for the subfield of Software Engineering Economics. His is not the first such book (see, e. g., Barry Boehm, Software Engineering Economics, Prentice Hall, 1981 or Leon Levy, Taming the Tiger - Software Engineering and Software Economics, Springer-Verlag, 1987) but it is the most thorough and up-to-date one that I know. It is an excellent book on a very important subject. Every professional software engineer, whether CTO, group manager or programmer in the trenches, will benefit considerably from reading this book.
   Return on Software is divided into several major parts: general concepts of business decision-making, interest and the value of money, and cash flow streams; business decision-making at for-profit companies; decision-making at government and not-for-profit organizations; estimation, risk and uncertainty; and decision-making based on criteria other than money such as reliability, quality, speed, and other important features (strict economists might argue that all of these other criteria could be equivalenced to money considerations but I think considering these other criteria on their own seems more natural to me).
   Judging from the topics listed above, Steve believes business decision-making to be the key ingredient of successful software engineering. I could not agree more. The crucial chapter in the book is #4: The Business Decision-Making Process. The key topics in this chapter include understanding the real problem, defining the selection criteria, identifying all reasonable technically feasible solutions, evaluating those proposals, selecting the preferred proposal, and monitoring its performance. The remainder of the book is an elucidation of those topics.
   Each chapter closes with a summary and a set of self-study questions supporting the book to being used as a textbook. My university will offer a course around "Return on Software" in the spring quarter for our Master of Software Engineering students and I expect the course to be offered regularly. The last time I checked, Steve's company was not offering a short course on his book's topic but it would not surprise me to see one soon.
   To prove that I am not from the publisher's marketing department, I would like to suggest that the next edition include at least two more topics: buy-or-build decision-making and outsourcing (whether offshore or not).



3. First, a confession, I know Steve Tockey. I work with Steve. That may bias my review a bit depending on how much I like Steve. One thing about Steve is that he home brews many nice beers and brings them into work where we get to share. I like Steve.
   I also like his book. Now, I will admit that this is no thriller where you are excited to turn the next page (though I did get a little worked up on Analytical Hierarchical Process). It is designed to be an entry level economics text for the world of software engineering. The world of computer science and software engineering needed a book like this and didn't have one. So, Steve brewed this one up.
   Part one (chapters 1-9) contain the basic economic theory you would find in most basic economic books. The topics are based around making decisions to make the most money (for profit companies) or to deliver the most benefit (non-profit). The text in these sections tends to get acronym heavy and Steve had to use the equation editor to type all the fancy mathematical formulas needed for things like interest for equal-payment-series capitol recovery. If you have had a basic economics course in college you can probably skip the first part without any pain. If you haven't or had forgotten (like me), then reading them is warranted. I found Steve's prose on this very dry subject to be reasonable.
   Parts two through five carry on in the same way (chapters 10 - 20). Part two in decision making in for-profit companies and part three is advanced decision making in for-profit companies. Again, if you have concepts like Minimum Attractive Rate of Return, Cash-Flow Streams, Planning Horizons, Sunk Cost & Salvage, Inflation & Purchasing Power, Depreciation, Modified Accelerated Cost Recovery System, etc. then you can skip these sections. Same sort of story for part four, decisions in non-profit companies and part five, present economy.
   BUT WAIT, there is part six! Estimation, risk, and uncertainty. Now here is a section that everybody should read, at least a couple of times. In my work and consulting, I find I am recommending to my clients that they read this section carefully. People building software seems to really miss these economic concepts. Steve does a very good job here in explaining how estimation, risk, and uncertainty work together (often against) on a work effort. He then provides several decision making strategies that work within the reality of uncertainty.
   Part seven completes the teaching part with working with multiple-attribute decisions with a good discussion on number theory and how to rationally make comparisons. This is another section that I find most people don't understand too well and highly recommend that everybody reads this part.
   There is a part eight but it is a summary and conclusion.
   So, my bottom line is that some parts of the book are a must read. So parts are a could read. If you don't mind skimming the parts that you know or are not applicable for the current situation, this book should work out fine. It is also one of those books that you will actually pull off the shelf next time you are asked to lead the selection of a new Commercial Off The Self (COTS) system, choose between two competing project ideas, or just want to make a better personal finance decision.



4. Engineering is the practical and economical application of science in building products and services. So it puzzles me how financial aspects are so often neglected in teaching Software Engineering or Computer Science. What a big mistake! This is a skill that no Software Engineer should left unmastered. By the way - this is very useful even if you're not dealing with software and for your private life as it allows you to make informed decisions based on a sound rational. Steve Tockey writes in a very concisive and interesting way and provides several examples for each topic. I highly recommend it!



5. Even though there is not a single line of code in this book, it is one that all people who are involved in the process of managing software development should read. In most cases, investment professionals will have an easier time understanding it than software developers will. The decision to invest organization resources in a software development project is treated as an investment and the point of the analysis is to determine if it is a sound one.
   Part one starts with the fundamental concepts of how business decisions are made. Cash flow diagrams are used to illustrate how the flow of money relative to your organization can be visually modeled. Entire chapters are devoted to the various ways interest can be computed, the formulas used to compare the net worth of two different proposals and how to develop mutually exclusive alternatives. A large number of formulas are used, so if you are unfamiliar with the mathematics of finance, you will probably have a difficult time understanding them.
   Parts two and three deal with how to make decisions in for-profit companies. Decision analysis, economic life, replacement decisions, salvage value, factoring in inflation/deflation, depreciation, cost accounting, and the impact of income taxes on business decisions are all examined using formulas, charts and diagrams. At times it gets very technical. To give you some idea, here are the titles of some sections:
   
   *) Calculating after-tax cash-flow streams.
   *) Inflation and after-tax cash-flow streams.
   *) Gain or loss when selling or scrapping depreciable assets.
   *) Comparing financing methods in after-tax cash-flow terms.
   
   Part four deals with making decisions in government and nonprofit organizations. This is a very short section, less than twenty pages in length. Since these organizations generally cannot lose money either, the main focus is on the different ways government and nonprofit organizations finance their expenditures. Part five covers present economy, how to do break-even and optimization analysis. The primary focus is on how to perform various types of break-even analysis.
   Part six examines estimation, risk and uncertainty. How to recognize and model the level of uncertainty and how to make decisions in situations with a great deal of uncertainty. This requires some knowledge of the fundamentals of probability and expectation. The last section covers the situation where there is more decision criteria than just the basic cost. This of course can be rather difficult, as it can enter the area of personal opinions. It is often due to the ordinal form of the data, where the range of assignments can be something like, {very poor, poor, average, good, very good}. While all can agree that poor comes before average, what one person will consider average, another would categorize as good. Fortunately, it is fairly easy to assign numeric values to the categories for standard numerical analysis of the data.
   This is probably the hardest "computer" book I have ever read. I know a reasonable amount of financial mathematics, but it was still difficult to wade through all the equations, charts and diagrams. Despite this difficulty that you will most likely also face, I strongly encourage all managers to thoroughly study the contents. There is a set of self-study questions at the end of each section and solutions to most of them are included in an appendix. The software development industry has a (largely deserved) reputation for lax financial planning and the person who reads and comprehends the material in this book will have an enormous competitive advantage in the battle for jobs, revenue and profits.
   
   Published in Journal of Object Technology reprinted with permission

No comments about JBoss in Action: Configuring the JBoss Application Server.

5 comments about C# for Java Developers (Pro-Developer).

1. i could have sworn this book was from microsoft press. This book did a *great* job of being unbiased, and presented "just the facts". It did so in such a clear manner as well, straightforwardly laying out the similarities and differences between java and C#, and each's strengths and weaknesses (briefly).

   definitely recommended!




2. This was truely an amazing book, I've read many .NET books, all of which assume zero knowledge of programming, or very little. So when I skipped the first few chapters, or skipped them (Since I've been a Java Developer for several years), I missed valuable differences between Java and .NET.

   Be sure you do know your stuff in Java, or else this book will seem over your head. This is not a beginners book. But if you're a Java developer, or have similar programming experience, this book is 100% for you.

   My only quirk with this book, is that at times, it's more of a refrence/comparison, over how to use several key .NET features. And it seemed to jump around a little. So actually I'd probably rate this book a 4.75...but rounding up gives us a 5, which it pretty much deserves.

   I highly recomend this book out there for anyone who is NOT a beginner programmer, or comes from a Java background. This book is a MUST read for you.




3. This books hits the spot for java developers, the intended audience. A one page description on delegates, for example, has all the information you need to get started with delegates. The Oreilly book has a long winded chapter on it and the essence was lost in the obtuse example provided.



4. After about 5 years as a java developer, I took a new job as a .NET / C# developer. This book was a great starting point for me. Going from java to c# is a relatively easy transition, but this book makes it much easier and quicker. The book compares the two languages and highlights the differences which made it easier for me to pick up. I'm not a person who reads many books, for work or pleasure, so I don't have much to compare it with. But out of the 10 or so books in my work library, this is the second best book I've used. (The best I own is Effective Java. I'd really like to get one like that for c#.)



5. As an experienced Java developer who was "forced" to move into the C# and .NET world, I turned to this book to help me make that transition. I am very glad I did so. This book provided nearly all of the background I needed for that transition, and it still serves as my primary C# reference a year later. (By the way, working in the C# and .NET world is not as bad as I feared it would be.)
   
   If you are accustomed to Java and new to the world of .NET and Microsoft books in general, you will find the majority of these books to be written for a less sophisticated audience than you are used to. My advice is to be very cautious what you spend your money on, as many of the books about Microsoft programming topics are not worth the investment.
   
   This book, however, is very much worth the money you will spend on it.

5 comments about Patterns for Effective Use Cases (The Agile Software Development Series).

1. While Alistair Cockburn's "Writing Effective Use Cases" book is great for learning how to write use cases, this book takes it to the next level. It enables the reader to understand the issues that teams face when dealing with large numbers of use cases.

   The authors cover the pragmatic issues that teams face, providing many real world examples and anecdotes. The pattern language is easy to read and apply on projects. The basic ideas of the pattern language are clearly expressed in the pattern names, for example, "Small Writing Team", "Participating Audience" and "Writers License". The summary on the inside cover provides a handy reminder for those times when you know you are making a mistake, but cannot quite remember the pitfall you are about to fall into.

   A great book that I heartily recommend.




2. The fact that this book describes a "pattern" named PreciseAndReadable should tell you what you need to know. If you need to be told that use cases should be precise and readable, or that you should name them with active verb phrases (VerbPhraseName), or that they should describe things of value to the business people (UserValuedTransactions), or that you should involve those people in the process of writing them (ParticipatingAudience), or that you should stop writing them when they make those people happy (QuittingTIme), you'll certainly get some value from this book, but it's clear evidence that your problems run considerably deeper than this book will be able to address.

   This represents 25 pages of fundamentally simple content spread across 200 pages, and in a thoroughly pretentious manner to boot. Avoid.




3. The people who will be attracted to this book will be people who are really going to be involved in use case development, whether as actual writers, consulting engineers, subject matter experts, managers, or any other stakeholders in the process. Overall, I found the book to be well written, quite engaging, and, in the main portion where all the patterns are described, nicely organized to enable the reader to almost subconsciously understand how to navigate the pattern language. From a patterns perspective, the collection is more like a true pattern language than many other collections that make such claims and the interrelationships and movement through the language show that the authors did a great deal of work to make the language comprehensive while still keeping it lean. Although I am a veteran use case writer, in reading this text I learned many things that I wish I had known when I was in that practice. The authors have done a superb job at extracting what is the essence of good practice at all levels in developing use cases, and I think that the book could find a spot on many, many software professionals' shelves. Even more importantly, I think they would actually read it. In fact, I think they would study it. I know I did.



4. Patterns for Effective Use cases is a must read if you need to develop for a software application. The authors describe what makes for a good use case, and make the points memorable with stories, and examples. If you have lots of experience writing use cases many of the patterns will cover things that you already know, but the way the patterns are presented make for an effective tool to help you teach others how to write a good use case. The pattern language format makes it clear that any single practice will not make for a good use case, you need to take a number together, otherwise you may have something that looks good at first glance, but just does not work.

   I recommend this book for anyone who is learning to write use cases, or for experienced people who want a refesher course.




5. This book attempts to take use cases to a higher level of science and in part succeed. Its plus points are discussions on management of use cases and the processes a team goes through in completing the creation / validation cycle. There's a lot of good sense here. Some of the patterns are useful. However, there's also a lot of regurgitation from various other texts and papers, some written by the authors themselves. And some key aspects are missing, aspects that are really important to industry and others that have concerned academia. Industry is not too worried about how to name use cases these days; that's easy. They want to be able to estimate how long it will take to build the system from use case points, for instance, or how to achieve forward traceability to the design and maintain traceability back to the requirements and business strategies (not the same thing exactly as the use case goal - which typically is not to stuff up and to make the principal actor happy). Academics are concerned too with effort estimation, with grammar and consistency checking, with dependencies and product lines, and non-functional requirements and whether use cases are at all to do with requirements in the first place and what they are no good for. Not whether we can build a little online booking web site - we can already do that. Though the book does not set out to answer these difficult questions, in its 200-odd pages, it ought to have, since this is what we really want to know about. So, though the book is excellent on what it does address, there's a lot of over kill in this. What's missing is what it does not address - all the hard problems we really need answers to.

2 comments about Practical JBoss® Seam Projects (Practical).

1. I purchased this book after previewing several other books and online resources in order to get up to speed on both the overall architecture of Seam and get a good concrete hands-on ramp up of the technology for a development project I'm currently working on to transition from a proprietary J2EE MVC application to a Seam-based system.
   
   Farley's approach to establishing a base application using standard JavaEE technologies and API's (JSF, EJB3, POJO gluecode/configs) and then walking the reader through the migration and enhancement of said application with Seam is very well delivered and serves to illustrate both the benefits of Seam as well as provide an understanding of why various aspects of Seam exist (e.g. annotation-and/or-configuration for component binding, enhancement to the JSF response lifecycle, the conversation context and application flow/BPM, etc.). By taking this "Practical" approach, I was able to rapidly get up to speed on the core principles of Seam and move past the usual configuration/familiarization thrash that one encounters when learning a new framework.
   
   The book's presentation is a comfortable conversational style but still well structured and the author takes the time to review and reference core concepts without the burden of diving too deep into the foundational technologies (which can be better researched in their own volumes/sites/forums).
   
   The only criticism I have is lightness on describing how to implement Facelets in Seam, but given that the JSF foundation is largely identical to a stock JSF implementation, it's a smooth configuration tweak to start using said technology with Seam (read: Google it).
   
   Highly recommended to anyone who already has a working knowledge of JEE5 and the core technologies as well as a great primer for what will be baked into JEE6 in the near future.



2. As the name applies, this book is OK for looking at some specific projects using JBoss Seam; however, some parts that I think should be there are not. Red Hat has JBoss Developer that works great for their SEAM product howeve this boo metions nothing about using that studio or even that it exists. I would expect a book such as this would at least have an appendix that would explain the developer studio, setup and running under the JBoss Server. This is why I could not give it 5 stars. This aside, the examples are rather specific and complete and you can certainly save yourself time by downloading the source code from the [...] website. In fact you can even purchase an electonic copy of the book [...] for those that own the printed copy. On the second to last page of this book is the information that you need to go online, purchase the online version (using your CC or PayPal) and then download it to your PC. Since I run around a good deal, I bought this electronic copy and then placed it on my flas (thumb) drive that I carry everywhere. This way I am never without the material. This book is good for those already familiar with the basics of SEAM but if you need some beginning information try the other book from Apress called "Pratical JBoss Seam: From Novice to Professional."

1 comments about Game Level Design (Game Development Series).

1. This book offers a solid foundation for the planning stages and a good overview of the implementation stages of level design. Good for those who are looking for general strategies for level creation and wanting to get up to speed on terminology/workflow for this type of work. It's all fairly theoretical with only one chapter on actual nuts and bolts level design, where you make a single room in the Unreal editor. If you're wanting something covering more specifics for a given level editor (like 'how do you create water?' or 'how do you make displacements') you should probably look for something more in a technical bible or a video tutorial series for the tool in question.

2 comments about Pro SMS 2003 (Field Guide).

1. Although there have been several SMS 2003 related books released lately (and long overdue in my opinion), each one has something additional to offer to the SMS Admin. SMS 2003 is a complex thing to understand and administrate, and I found "Pro SMS 2003" to be another useful addition to the books available. The emphasis placed in the first few chapters on understanding your network topology *before* starting to deploy important. Hopefully if a company is considering SMS they take to heart the planning stages as the critical step they are for a successful SMS deployment. The book also takes one through step-by-step setting up the agents, inventorying options, and some of the addons (like patch management and Feature Packs). To quote Rod himself "This is the book I wish someone had written for me when I first started working with the product."



2. This is a great book, and the author has kept it current. (It includes references to SMS SP2). Probably not for SMS beginners trying to learn the software, but it's loaded with great information. I keep it with me at work as a quick reference. Definitely worth buying!

5 comments about Proc SQL: Beyond the Basics Using SAS.

1. An experienced SAS programmer, I used the many helpful examples in this book to learn a lot about PROC SQL in just a few days. (I skipped the text.) I trust the few typos and obscure passages will be cleared up in a subsequent edition. I thought the sections on normalization and integrity constraints were skimpy. The book has also been favorably reviewed in The American Statistician 2005, vol. 59, no. 4, pp. 350



2. If you are new to PROC SQL, this is the right book. It covers all the basic queries, complex queries in simple content, some troubleshooting, and a little bit of efficiency. The layout throughout the book is very easy to read and follow. All examples contain PROC SQL codes, results, appropriate explanation, as well as part of SAS LOG and comparison in some examples. This book might be a little basic to power PROC SQL users. But compared to SAS SQL procedure user's guide, it is way better to have.



3. I purchased this book one year ago under the influence of the high ratings here, but I didn't get chance to finish it until last week. After comparing this book with the SAS SQL manual (free online PDF file available at SAS website), I came to one question, why bother to buy this book? The book is not a copy of the SAS manual, but it is written in a strikingly similar pattern yet it provides LESS information than the SAS manual; on the contrary, the SAS manual gives you more materials, more examples, better narratives, clearer explanations than this full-of-typo book.



4. I have read most of the chapters of this book. I certainly advise anyone who would like to learn SAS SQL or improve her/his SAS SQL skills.



5. This book is okay, probably wouldn't buy if I would have flipped through it first, but ordered online. Too many examples, not enough explanation on the actual examples. Alot of examples were redundant.

No comments about Programming in Python 3: A Complete Introduction to the Python Language (Developer's Library).

5 comments about The Game Producer's Handbook.

1. This is the book that de-mystifies video game production. What a fantastic handbook!



2. The book is very insightful of the anonymous role that bares the title "Producer." Producers ARE the backbone of development. They have to set the ground rules on game design and what actually gets developed for the consumer release. Without a good producer the development process will either never end or the game would fall apart to garbage, literally in one day. Producers seem to be the understated person in the development team. Many coworkers have snickered and have said things like "Of course he has a stupid big smile on his face. He's getting paid well to do nothing but order pizza." The obscure, daunting task of keeping together a big developing team, the assets, the budget, marketing, etc. all in line is an under appreciated feat. But somebody has to do it!
   
   I recommend this book to all people working on a team, and all the hopeful talents who want to partake in the videogame industry. Videogame development is a physical and mentally tasking process. Producers do carry the burden of easing the shell-shock of how a "cool" job is actually hard work by planning and organizing the development schedule. I feel the book gives a good recap of what is expected from producers. If it feels like something is missing (was that piece copyrighted) this is a good book to check, hence the name The Game Producers Handbook. Good producers could very well become great producer after reading this book. Leadership skills are essential. The book covers quality traits of a good producer briefly, which I appreciate, very to the point. If a person needs more self-help material on leadership I recommend a purchase of a Forbes magazine. But my favorite tip from Handbook, and it just common sense: when having a meeting have a written agenda and mind the allotted time because dev-time is a lot of money. Finally it has been written, thanks Dan.
   
   Another section of the book worth reading and following is the process of how to deliver, or pitch a game idea to get the production green light. It would have been nice to see the initial documents. I think everyone that has purchased this book was hoping to find the answer to how to get "my" game into development. For example, what exactly does the proposal document look like? Is it typed in formal-unbound report format? How much written is enough for a game proposal? What is too much and too confusing to read?
   
   Lastly, developers who are uncertain of the role of a producer may benefit by understanding the producer is your work-friend, not the pizza boy. Or the guy that cuts out your work because he (hates) you:-P Understanding the various roles in a game team makes better teams. Your producer already knows this. This book is sure-fire recommend to all my coworkers. I believe the more your aware of the process of making a video game, makes you a more valuable employee. Many work blindly to the task at hand, and do a great job. But I like to see the big picture. But hey that me.



3. After shipping over 50 different titles in 15 years (working in various capacities), I thought I knew it all. However, after seeing Dan's common-sense approach and mastery of the production cycle beautifully laid out, I suddenly found myself an aspiring student in several areas. In the others, it was an affirmation of what I know, believe, and have personally experienced.
   
   If you are an Assistant / Associate / Full-Fledged Producer--this book is for you. If you are someone who is striving to break into the games industry, again, this book is for you.
   
   Dan is currently the CEO of Threewave Software in Vancouver B.C. (if anyone is keeping tabs), and his knowledge and personality resonates throughout the book.
   
   Major kudos, a great read, and like the subject line says it's an invaluable resource for now and years to come.



4. This book is basically just a long list of platitudes, like "strive for excellence", "plan ahead" and "be nice to people". It contains very little of substance and is incredibly superficial.
   
   Apart from that, it is poorly organised (apparently every single paragraf deserves to get its own header!), extremely repetitive, and also contains annoying small mistakes (like referring to a reading list which doesn't exist).



5. I've been a game Producer for 8 years. Over that time I've had some successes and some failures. There is no doubt in my mind having this book would have prevented some of the failure. It goes very in depth into all aspects of a producer's job. I learned several new things from the book and can't wait to try them out on my team. I heartily recommend this book to anyone who is thinking about becoming a producer or anyone who currently is a producer.