Software

Review by Erick M. Griffin:

Testing Computer Software is one of the those rare books that has taken on the problems of the Verification Engineer. As all of us know, most books written today are targeted for the development audience and even many of these are either poorly written or try to cover too much area. This book however, though broad in its scope, does a good job of treating all of the important areas in verification and testing. I have found Chapters 2, 3, 7, 11 and 12 to be the most useful and poignant to the average engineer. Not only is each chapter well laid out, but the authors also offer compelling arguments in each chapter to back up their arguments as well. I enjoyed particularly Chapter 3 the section on Path Testing, which conjures up horror stories from my development days. In this section the authors assert that 100% path testing does not imply 100% test coverage. They go on to argue with some rigor why the two are not necessarily the same. Many of you as I can probably claim that though all of the paths in their code were tested, verification was still able to find some condition that would make some part of the code fail. This chapter explains why this may be so and methodologies on how to attack testing those areas. You will find the book well structured, informative and actually intuitive to navigate through. Each chapter builds on the previous chapters to provide the engineer with a clear idea of all the steps and intricacies involved in testing and verifying complex programs. It can therefore be used by the beginner as a source book for specific test applications, or by the team lead or manager who needs to know more about the actual scope and planning of a complex testing project. This book surely fills a great void in the area of publications software verification.

Review by Bret Pettichord:

This book should sit on the desk of every software tester.Many books will tell you how to test when you have enough time and cooperation. This book tells you what to do when the schedule is tight, the specification is missing, and the developers are tired of your focus on problems. It has sound advice and is a pleasure to read. I keep coming back to it. Feel like you have an impossible job? Read this book.(Note: this book was published in 1993 and has not been updated since then. Wiley lists 1999 as the publication date because that was when they became the new publisher for the book, which is destined to become a classic.)

Review by Layla:

Hofstede is, of course, the pioneer of culture studies in business and organizations. This book is a simpler and more accessible version of the more comprehensive – but also more difficult, ‘Culture’s Consequences’.

He begins with an excellent overview of culture and its levels and explains the concept of cultural `dimensions’ – aspects of culture that can differentiate and measure differences among different cultural groups. The book then proceeds to present the four dimensions of culture that he identified as a result of a massive survey he conducted on IBM employees in 72 countries in 1968 and again in 1972. Additional data was later collected from other countries and populations, outside IBM, and used to verify and enhance the original results.

However, in this book, Hofstede discusses his four original dimensions of culture: Power Distance; Uncertainty Avoidance; Individualism & Collectivism; and finally Masculinity & Femininity. The fifth dimension which was later added based on results from the Far East and Asia – Long- versus Short-Term Orientation – is not discussed in this book. Despite that, it remains a very valuable and highly readable introduction to the topic from the man who pioneered the field and popularized it among business people, multinationals and business researchers alike.

Hofstede also uses these dimensions of culture to ‘classify’ organizations to different types according to where they fall on the Power Distance vs. Uncertainty Avoidance grid. The discussion is highly informative and touches on Mintzberg’s theories as well typical models of organization in different cultures. In Part Four, he discusses how intercultural encounters are affected by these dimensions and how awareness and acceptance of these differences can yield more effective results.

Review by Gerard Kroese:

Geert Hofstede is Emeritus Professor at Maastricht University in The Netherlands. He was Professor of Organizational Anthropology and International Management at the University of Limburg (which was later re-named Maastricht University). He is the founder and first director of the Institute for Research on Intercultural Cooperation (IRIC), where a lot of the research used in this book comes from. This paperback version was published 3 years after the hardcover and includes some updated references to political events. This book is largely an extension to Hofstede’s 1980-book `Culture’s Consequences’. The book consists of 4 parts.

Part I – Introduction, consists of one chapter, and lays the foundation for the remainder of the book by introducing the meaning of `culture’ and a small vocabulary of essential terms. He also discusses the objective of the book: “to help in dealing with the differences in thinking, feeling, and acting of people around the globe. It will show that although the variety in people’s minds is enormous, there is a structure in this variety which can serve as a basis for mutual understanding.” With reference to the definition of culture, we need to understand the book’s subtitle first. `Software of the mind’ is patterns of thinking, feeling and acting (which were learned throughout a lifetime). Hofstede’s definition of culture is “the collective programming of the mind which distinguishes the members of one group or category of people from another.” It is important to note that he believes that culture is learned and not inherited. He continues with a brief discussion on the 3 levels in human mental programming: 1. Human nature (universal; inherited); 2. Culture (specific to group/category; learned); and 3. Personality (specific to individual; learned and inherited).

Part II – National Cultures – is the largest section of this book with 6 chapters and deals with differences among cultures at national levels. Chapter 2-to-5 describe the four dimensions empirically found in research across more than 50 countries: (1) to wit power distance; (2) collectivism versus individualism; (3) femininity versus masculinity; and (4) uncertainty avoidance. Each of these 4 chapters follows the same structure: description of dimension, the scores of the various countries, the consequences of the dimension for family life, school, workplace, organization, state, and the development of ideas. Chapter 6 looks at the consequences of the national culture differences in the way people in a country organize themselves, combining the dimensions from the previous chapters. The next chapter introduces a fifth cross-national dimension, which is long-term versus short-term orientation. This reveals deep differences between Eastern and Western thinking.

Part III deals with differences in organizational culture and consists of only 1 chapter in which the author describes the insights collected in IRIC’s research project across 20 organizational units in Denmark and the Netherlands between 1985-1987.

Part IV – Implications – consists of 2 chapters and discusses the practical implications of the culture differences and similarities. The first chapter of this part discusses what happens when people from different cultures meet. It discusses phenomena, such as culture shock, ethnocentrism, stereotyping, differences in language and in humor. It also discusses the development of intercultural communication skills. The final chapter of the book summarizes the message of the book and translates it into suggestions for parents, managers and the media. There is also a speculation on future political developments, based on the cultural processes.

Yes, this is a monumental book on the `software of the mind’. I believe that this book is a fantastic piece of work on this subject, based on strong research, and is probably the starting point for anybody interested in this subject. I must warn people that the book is not a simple, fast read, since the information is very intense and the wide range of information covered. However, the writing style is good and there are plenty of tables, diagrams, figures to make the reading somewhat `easier’. Highly recommended to all people interested in this subject, from parents through to managers. (Where is the 6-star button?)

Review by Pat McGee:

This book contains 293 “Lessons”. Each seems to be meant for people with certain experiences and certain problems; some very broadly defined, others more tightly. So, how do I grade 293 lessons? One way would be to average them, another to pick on the worst (from my point of view). I choose to pick out the ones that hit me the hardest; the best from my point of view.I’ve been a developer, a tester, a test manager, and am now a grad student studying testing with Dr. Kaner. This book was the proximate cause of the last. If I had had this book a couple of years ago, I believe I would have done a much better job as test manager, and my project would have succeeded better with our customer. This is the second best book on testing that I’ve ever read.By the time I saw Lesson 31, I had already learned it the hard way. “A Requirement is a quality or condition that matters to someone who matters.” It doesn’t matter what the requirements document says; you ignore the opinion of someone who matters at your peril. I did.Lesson 57: “Make your bug report an effective sales tool.” My bug reports developed a pretty good reputation with most of the developers, so I quit paying as much attention to putting convincing arguments in them. Then, we got some new senior developers. I was back at square one without quite realizing how I got there. Don’t do that.Lesson 235: “Staff the testing team with diverse backgrounds.” When I became test manager, I looked for people like me: computer science degree with developer experience. Well, such people don’t work as testers, especially for the location and money we offered. I first hired a young woman with Army training. Later, I figured out how lucky I had been; she was one of the two best testers who worked for me. I learned a lot about my blind spots from her pointing them out to me. I’d hate to have tried to do the job without her or many of the other people very different from me (and her) that I hired.Lesson 240 “During the interview, have the tester demonstrate the skills you’re hiring for.” After having a lot of bad results from traditional interviewing, we wrote a series of tests and gave the appropriate one (testing, SQL, C++, etc.) to each candidate. Afer that, we found our rate of bad hires was down sharply. We hired several people whom we would not have hired based on our traditional interview questions; almost all turned out well.What am I learning? Lesson 17: “Studying epistemology helps you test better.” I hope so; I’m studying it. Lesson 76: “Always report nonreproducible errors; they may be time bombs.” I’m keeping more lists of these now. No good results yet. Lesson 266: “Learn Perl.” Yep, there’s more than one way to do it.(BTW, the best book on testing I’ve ever read is Testing Computer Software, 2nd. Kaner, Falk, Nguyen.)

Review by Richard Cowand:

I noticed that many of the reviewers listed above are noted SW testing professionals that have published books themselves. I also noticed that these same professionals tend to supply glowing reviews for each other. I think this might lead to a bit of a bias that could mislead ordinary folks looking for a good reference tool to help them do their job.I’ve been in the SW test business for several years and have used Cem Kaner’s “Testing Computer Software 2nd Edition” as a bible for many years. Mr. Kaner’s “Lessons Learned in Software Testing” is a great help for both rookies and seasoned veterans alike, but mainly for anecdotal wisdom. I wish I had the opportunity to read this book early in my career, it would have prevented some of the painful lessons I’ve learned about the testing business. At the same time, portions of this book are opinions and observations, and should be read with an open mind, but not read as gospel. I often read sections of this book to reassure myself that my actions/decisions/processes are sound.This book is not a “how to” guide with sample forms and processes to follow, but a very useful collection of wisdom from some of the best minds in testing. Think of this book as three wise people sharing their knowledge with anyone willing to listen (or ante up the bucks to buy the book).

Review by Michael Davis:

—> To swing for the fence, entrepreneurs must avoid the shark-infested red water and sail into the deep blue sea.

If you’re even thinking of creating a software startup, I highly recommend you read The Business of Software as soon as possible. Doing so will save you much pain and suffering from senseless mistakes. When there is such a large body of existing knowledge, there is no cause for trial and error mentality. There’s plenty of other opportunities for trailblazing. Read this book as a bare minimum before starting your venture.

Cusumano, offers an in depth study of what it takes to succeed in software. Of particular value are critical questions to contemplate:

1) Do you want to be mainly a Products company, or a Services company?

2) Do you want to sell to Individuals, or Enterprises | Mass market, or Niche market?

3) How horizontal (broad) or vertical (specialized)is your product or service?

4) Can you generate a recurring revenue stream that will endure both good and bad times?

5) Will you target mainstream customers, or do you have a plan to avoid the chasm?

6) Do you plan on being a Leader, Follower, or Complementor?

7) What kind of character do you want your company to have?

Cusumano also offers eight Critical Success Factors that are necessary for Software Start-ups to succeed as a business and raise investor money:

1) Strong Management Team

2) An Attractive Market

3) A Compelling New Product, Service, or Hybrid Solution

4) Strong evidence of Customer Interest

5) A Plan to Overcome the “Credibility Gap”

6) A Business Model Showing Early Growth and Profit Potential

7) Flexibility in Strategy and Product Offerings

8) The Potential for Large Payoff to Investors

Don’t reinvent the wheel. Read this book as soon as possible, preferably “before” you create that software venture you so boldly dreamed.

Michael Davis, Byvation

Review by William McMichael:

Cusumano presents a solid overview of selected topics relevant to the software business. He focuses on the following topics: strategy for software companies, best practices in software development, and software entrepreneurship. He makes use of case studies and provides insight on the inner workings of Microsoft, IBM, Netscape, Business Objects, and i2. In the chapters discussing strategy, he analyzes product versus service focused organizations. He also discusses market segmentation and whole product solutions as described in Geoffrey Moore’s “Crossing the Chasm.” With regards to best practices in software development, much of the material is from “Microsoft’s Secrets.” Cusumano describes the pitfalls of waterfall development and describes the key concepts of Microsoft’s synch and stabilize technique. A few pages are devoted to outsourcing and specifically the rise of the Indian software business. I would have expected more analysis on some of the newer agile development methods — such as XP. Lastly , Cusumano covers software entrepreneurship. He provides an eight point framework to evaluate a software start up. Does it have the following characterisitcs ?
1. Strong management team
2. Compelling new product, service, or hybrid solution.
3. Strong evidence of customer interest
4. An attractive market
5. A plan to overcome the credibility gap.
6. Business model showing early growth and profit potential
7. Flexibility in strategy and product offerings
8. Potential for large payoff to investors.
The text also has a useful appendix with income statement analysis of Business Objects and i2 , and growth comparisons between various organizations. There is nothing in the text I would consider groundbreaking, but it is a solid overview of the software business appropriate for software managers and entrepreneurs.

Review by Lasse Koskela:

‘User Stories Applied’ was a book that long stood on my Amazon wish list with a ‘must have’ rating. I’m not disappointed. I loved the book. Now let me explain why.

First of all, running the planning aspect of an XP project, for example, well is essential for reaping the benefits of agile software development. Yet, relatively little has been written to guide practitioners in doing that. I, for example, have made all the mistakes Cohn enumerates in the chapters for guiding the user towards writing *good* user stories (usually more than once). These sorts of things make you realize you shouldn’t put the book on the shelf to gather dust! The author doesn’t cover just writing good user stories, but the whole spectrum from putting together the customer team to estimating stories to discussing the stories to writing acceptance tests for the stories.

Second, it’s a pleasure to read. The structure makes sense, each chapter is followed by a useful summary, and there’s a set of questions — along with answers — to make sure you understood what the chapter talked about. Usually these kinds of Q&A sections simply force me to skip them over. The questions in this book did not. I read each and every one of them and I think there was only one set of questions that I did ‘pass’ with the first try, usually having forgotten some rather important aspects to consider (concrete evidence of their usefulness to me). To finish, the last part of the book, an example project, nicely ties together all the threads.

As usual, there were some things I experienced not so well. I believe the chapter on applying user stories with Scrum could’ve been left out without breaking the plot. Also, I think a typical user wouldn’t have been bothered about dropping the appendix introducing Extreme Programming.

In summary, this is the book to get if you’re involved with user stories. I had to pause reading every few pages to scribble down some specific tips. I’m confident that you will too.

Review by Lisa Crispin:

This excellent book is a must-have for anyone on an agile team – developers, testers, business experts, analysts – and for anyone who struggles with requirements, planning, or estimating on any software project.User Stories Applied is easy to read and digest. As the title suggests, its techniques are easy to apply and deliver huge value. Each chapter summarizes developer and customer responsibilities, and has questions whose answers are provided in an appendix. The book is full of real-life, concrete examples, allowing you to learn from the successes and failures of others. This book will give you many tools to help your projects succeed. Just a few of the most valuable topics:
When are user stories too big, too small, too detailed, too general, too open ended, when are they not user stories, and how to correct all these.
Why use user stories.
How to handle requirements for infrastructure, performance, qualitative aspects, UI.
How to ask questions to elicit requirements.
How to cope when you don’t have `on-site customers’.
Practical ways to estimate stories.
Monitoring velocity and progress.
When to keep and when to discard artifacts.Mike explores the differences between stories and other techniques for delivering requirements: IEEE 380, use cases, scenarios. He points out many positive side effects of user stories, such as encouraging participatory design and tacit knowledge accumulation.I particularly like that the book emphasizes the team’s responsibility to successfully complete each iteration. I enjoy Mike’s illuminating bits of wisdom, such as the “everything takes 4 hours” example. I love the comprehensive example in Part IV. No matter what your level of experience, you’ll put the ideas in this book to immediate and productive use.

Review by Peter S. Hamlen:

I found this volume to be extremely useful. It contains very insightful commentary on what architecture is (a term that I find is misused a lot), what architecture affects, and how to evaluate the qualities of an architecture.Two of their best insights for me:* Architecture affects the organization of the company/business unit. (In my company, we didn’t realize this and we failed to create an organization that could support the architecture.)* Virtually any architecture can accomplish the functional needs of a system – what differentiates architectures are how they provide the essential qualities (performance, modifiability, maintainibility, etc.) to the product.The book is strongly based in the real-world, with practical examples. I never felt they were straying into “theorectical” land.I also bought “Applied Software Architecture” but didn’t like it nearly as much – I highly recommend “Software Architecture in Practice”!

Review by ART SEDIGHI:

Being a Software Architect, I can certainly appreciate the work that the authors of this book (L. Bass, P. Clements, R Kazman) have put into this book. Software Architecture in Practice is probably the best book that I have read on the theory and practice of architecture design and software engineering. There is no fair way for me to review this book as it is PACKED with useful information from beginning to the very end. It has a combination of high-level architectural concepts tailored with best software engineering practices. It is not a complete book on software engineering, but it wasn’t meant to be – it’s meant to cover a very specific topic in software engineering and it does so extremely well. It is a text in which the concepts architecting software applications, evaluating architectures thru various methods, and case studies of major leaps in software architecture have been very well described; depicted and well evaluated. The book is written from an architect’s point of view, and it shows how an architect or a group of architects can make or break an organization, and what they need to do in order to be successful. The authors of this book explain why simply architecting something is not good enough and lots of work needs to be done before and after the architectural phase to ensure the quality and the success of the project. This aspect of the book is simply priceless. The author start by describing software architecture as:”The Software Architecture of a program or computing system is the structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and the relationships between them.”Throughout the book, the author used this definition to describe various aspects of architecture. One of the methods/techniques that the author uses is called the Architecture Business Cycle (ABC). ABC is method of realizing the “things” that influence the architect and in-turn the architecture – known as the circle of influences. This concept, ABC, is used for all the case studies mentioned in this book:

· A case study on a system that have extreme safety requirements – the Air traffic control.
· A case study on a system with high level of distribution of its subsystems – A flight simulator
· A case study in which it was essential for the organization to be able to share documents instantaneously.
· A case study on an organization where one architecture lead to a product line of applications
· A case study on the need to standardization of architectural approaches across organizations and the community – J2EE and the EJB.For each case study, the authors depict its ABC and give the reader the reason, business reason, that this project got started to begin with. The reader then walks thru a series of decision-making steps that led to the architecture that was finally chosen. The drivers of the project, the business reason, the architect[s], and the organization are all linked and the authors go into a GREAT DETAIL on how this link can influence the final design. Architecture Tradeoff Analysis Method or ATAM is a new topic that is added to the second edition of the book. ATAM is a structured method of evaluating architectures. “It results in a list of risks that the architecture will not meet its business goals” The authors start by describing the roles and responsibilities of people involved in ATAM, and the output artifacts that ATAM will produce when completed:· A Concise presentation of the Architecture
· Articulation of the business goals
· Quality requirements in terms of collection of scenarios
· Mapping of architectural decisions to quality requirements
· A set of identified sensitivity and tradeoff points
· A set of risks and non-risks
· A set of risk themes. The process of ATAM is depicted next in which there are a total of 4 phases: 1) Partnership and preparation: the key project decision makers informally meet to work out the details of the ATAM process.
2) Evaluation phase – the long evaluation process of the architecture with the same project decision makers as in previous phase
3) Evaluation phase, continued – this time the stakeholders are present
4) Follow up – the stakeholders and the evaluation team meets again to follow up.The process is described very well and examples forms are shown in the book that can be used for your evaluation process. The great thing about this chapter and how it’s written is the way that the ATAM process is presented. It is almost like a checklist that the architects need to follow. Very easy to read and follow. The inputs of every phase are clearly identified, and the description of the output is depicted rather clearly. The chapter ends with yet another case study that shows the “theory” just presented. The authors close the chapters by having the following comments about this book:
· ATAM is not an evaluation of Requirements, but only the architecture
· ATAM is not a code evaluation
· ATAM does not actually involved system testing
· ATAM is not a practice instrument, but identifies possible areas of risk within the architecture.
The ATAM is followed by another very well written topic on CBAM (Cost Benefit Analysis Method). This chapter is also new in this edition, but I will leave the details of this chapter for the reader. I like the ATAM method more than the CBAM, because it seems simpler to me.
All and all, the authors in this book did a fantastic job in writing this book. This book is packed with useful information for architects, project leads, and even technical managers.

Review by Michael A. Alderete:

This is a very good book, to the right audience. It is first and foremost an introduction to programming, second an introduction to programming in an object-oriented language, and third, an introduction to Java.So, the keys to liking this book are:1. You have not programmed before, or only a little2. You want to learn to program in an object-oriented language3. You want solid skills, not to add Java to your resumeIf your main goal is to learn Java, or to learn enough Java to apply for a Java programming job, there are better books. In this book Java is a means to an end, that of learning to write software. You’ll learn a fair amount of Java — nothing to sneeze at, definitely — but it’s only the first step of many towards mastery of the Java platform (which is *huge*, no one book will tell you all you need to know).If, on the other hand, you don’t know how to program, and think you might like to learn, this is a pretty good book, and you’ll learn enough Java to be ready for the next level.

Review by lilshe:

This is the book required of my Intro to Programming in Java class, which is a class designed for those intending to pursue Computer Science as a major. I believe the book itself is just that: a great introduction for those serious about learning to program and then take it to a higher level with further education.This is not an easy book to read with a light head. You cannot breeze through the code, which is explained minimally, or not at all, and expect to understand what is going on. Careful tracing and retracing of the code is what it takes me to understand some of the example programs. This said, once I’ve done so, I come away with a solid understanding of the concepts introduced.
Some of the chapters are especially lacking. I found the chapter on recursion to be confusing and hard to decipher until the professor gave us some solid real world examples (Russian stacking dolls) and a thorough explanation of what the code is doing. Others chapters were better than my professor in explanation, namely the chapter on loops and that on objects and primitive data.
I am taking this course with absolutely no programming experience, and am finding this book to be an invaluable complement to the lectures. However if you have no programming background and want to learn Java solely from this book, you would need more discipline than I have to do it. If you already have experience in programming, I’d imagine this book would help you to learn Java quickly and easily. If you’ve already done object-oriented programming some of the first chapters may be a little too basic. Overall this is a great book for those new to programming but dedicated to through study and further education, or as an intro to Java for those with prior experience.

Review by Richard Bejtlich:

I read six books on software security recently, namely “Writing Secure Code, 2nd Ed” by Michael Howard and David LeBlanc; “19 Deadly Sins of Software Security” by Michael Howard, David LeBlanc, and John Viega; “Software Security” by Gary McGraw; “The Security Development Lifecycle” by Michael Howard and Steve Lipner; “High-Assurance Design” by Cliff Berg; and “Security Patterns” by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw’s, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the production of more security software.

Gary McGraw’s book gets my vote as the best of the six because it made the biggest impact on the way I look at the software security problem. First, Gary emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). He shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. Gary applauds the diversity of backgrounds found in today’s security professionals, but wonders what will happen when this rag-tag bunch (myself included) is eventually replaced by “formally” trained college security graduates.

Second, Gary explains that although tools cannot replace a flaw-finding human, they can assist programmers trying to avoid writing bugs. Gary is the only author I encountered who acknowledged that it is unrealistic to expect a programmer to keep dozens or hundreds of sound coding practices and historical vulnerabilities in his head while writing software. An automated tool is a powerful way to apply secure coding lessons in a repeatable and measurable manner. Gary also reframed the way I look at software penetration testing, by showing in ch 6 that they are best used to discover environmental and configuration problems of software in production.

Third, Gary is not afraid to point out the problems with other interpretations of the software security problem. I almost fell out of my chair when I read his critique on pp 140-7 and p 213 of Microsoft’s improper use of terms like “threat” in their so-called “threat model.” Gary is absolutely right to say Microsoft is performing “risk analysis,” not “threat analysis.” (I laughed when I read him describe Microsoft’s “Threat Modeling” as “[t]he unfortunately titled book” on p 310.) I examine this issue deeper in my reviews of Microsoft’s books. Gary is also correct when he states on p 153 that “security is more like insurance than it is some kind of investment.” I bookmarked the section (pp 292, 296-7) where Gary explained how the “19 Deadly Sins of Software Security” mix “specific types of errors and vulnerability classes and talk about them all at the same level of abstraction.” He’s also right that the OWASP Top Ten suffers the same problem. Finally, Gary understands the relationships between operators and developers and the importance of security vocabulary.

I was pleasantly surprised by “Software Security”. I reviewed an early draft for Addison-Wesley and wondered where the author was taking this book. It ended up being my favorite software security book, easily complementing Gary’s earlier book “Building Secure Software.” In my opinion, Gary is thinking properly about all the fundamental issues that matter. This book should be distributed to all Microsoft developers to help them frame the software security problem properly.

Review by Avi Rubin:

On the one hand, it is risky for me to praise this book. I make my living teaching and practicing computer security. If everyone writing software these days were to read this book, I might eventually find myself out of business.

Gary McGraw, one of the leading security luminaries int he world, has got it right. Security cannot be added to systems once they are built. It must be designed in from the very beginning. The security posture and design must be considered in every phase of the development of a system – from the early design to the actual coding of the instructions.

Gary has done a fanstastic job explaining how to build secure systems, and detailing the importance and complexity of software security.

I’ve always been a big fan of Gary’s, and with this latest installment in his 3 part series, Gary has provided readers with the most important advice and instruction to help keep the bad guys out of your systems.

Review by Ira Laefsky:

This uniquely pragmatic guide to managing software development in the startup or growing firm, is an “in-the-trenches book” detailing the necessary,useful and extraneous practices, tools, and documentation which govern the successful management of software projects. The author is both a graduate of Caltech and Berkeley and the possessor of 20 years of hard earned experience in the management of technology and software development projects. He provides templates and spreadsheets for the documentation his methodology requires. He is an advocate of moderate but carefully scoped tools and documentation, often preferring (on the basis of experience) simple spreadsheets and Gantt charts over more sophisticated project management tools. This book offers a careful balance between the best communication, management and coaching methods, for members of the software team, interaction with marketing and CXO executives and the software and paper tools which contribute to the success of a software development effort. Caveats and advice such as, “When the Sales Team Overpromises”, and “Where the Waterfall model is better than Agile methods” speak to the author’s experience with the real world issues of technology development in the growing firm. This is “the book” you need for successful management of software projects in the startup or moderately sized firm.

–Ira Laefsky

Review by Krzysztof Satola:

As you all probably know results matter. If you are a development manager in a small, growing company, you will be judged by the work and results of your development team. Your team must deliver quality software on time on budget and that software will have to please your customers.

At first this book seems to be like other management books but one thing makes it really different. Growing Software is written for managers working in small companies. In fact it is about managing software engineers in a small firm. Luis Testa shows many interesting aspects of working in small environments as oppossed to corporate ones. In small companies development managers have more influence on processes and workflows and as a result in a product definition. In small companies approaches must be systematic, simple and relatively straighforward. This book is about how to start and avoid common pitfals.

I work as a software architect managing software development team in a small company. For me this book is a nice, well written guide. It is an advice offer about how to succeed when faced with diverse challenges. It is about managing techniques, professional ethics and building relationships with other company’s sections like Marketing or Sales. It also helps to understand and care about relations with other managers, CEO and team members.

As I said earlier there are many good books about managing engineering teams and processes of these teams but this book’s greatest value is focusing on how things work in small companies that want to succeed. I definetely recommend this book especially if you manage an engineering team in a small company.

Review by Michael Cohn:

Books written during the first phase of agile software development have been about very specific practices we should employ. There are some excellent books on the Extreme Programming, Feature-Driven Development and Scrum agile processes. These books teach us “do a, b, and c if you want to do Extreme Programming” or “do x, y and z if you want to do Scrum.”In the last year we’ve seen books by Highsmith (Agile Software Development Ecosystems) and Cockburn (Agile Software Development) that represent the second wave of agile software development-that of learning to think agilely rather than following a prescribed set of agile rules. Mary and Tom Poppendieck’s book is the latest and best book for teaching how to think agilely.The book contains 22 “thinking tools.” The thinking tools are drawn from the world of lean manufacturing where they have helped improve product delivery speed, quality and cost. Each tool is presented as a guideline. Each thinking tool is described with enough detail that you can put it into practice; but, more importantly, the reasons supporting each are made explicit. So, instead of simply reading that it is good to “deliver as fast as possible” we learn how rapid delivery is supported by pull systems (where work is pulled into the current step from the prior step), how queuing theory helps us identify bottlenecks, and how to calculate the cost of delay (to see which bottlenecks are worth removing).This book is the perfect blend of highly actionable instructions and descriptions of why those actions work. I highly recommend this book to anyone who wishes to improve his or her software development process. The authors’ ideas are applicable both to projects using agile approaches today and to more traditional, plan-driven projects.

Review by Steve Berczuk:

This is an excellent discussion of how the principles of Lean Manufacturing apply to Software Development. The authors explain why the usual metaphor of software as manufacturing is not quite right, and why the metaphor of Lean Manufacturing is something we can learn from. The book is clearly written and the authors provide examples and anecdotes to help you to understand their points. This was a fairly quick read, and I am likely to refer to it often.