We have become used to product improvements being synonymous with something additional, more complexity, more to remember. John Maeda’s 10 laws of simplicity challenge this trend and provide usable guidelines for achieving simplicity.
The first law, Reduce, is all about how to achieve simplicity by thoughtful reduction by looking for the appropriate balance between how simple can you make it and how complex does it have to be. The Shrink, Hide, Embody (SHE) guidelines guide the search for simplicity. Is this larger than it needs to be? Can I hide some of the complexity? What can I do to communicate the qualities embedded in this product?
I am charmed with the 7th law, Emotion, that states that more emotions are better than less. He encourages the exploration of human feelings about design and points out that this varies from person to person. Aichaku is the Japanese term for a sense of attachment to an object. Written as two kanji characters AI (love) and CHAKU (fit) the image of “Love-fit” is a way of considering our emotional attachment to objects regardless of what they do.
Given how complex it is to achieve simplicity, the laws have a certain amount of overlap and contradiction and are best used as design heuristics rather than hard and fast rules. This slim book (100 pages) has followed its own recommendations and provides a simple and usable guide to simplicity.
Suzanne Robertson
This book at amazon.com amazon.co.uk Kindle edition

Here is a clear and practical explanation of what Systems Engineering is and how it is integral to requirements. The authors do a good job of explaining how requirements are the thread that holds everything together and keeps the software, organisational and mechanical parts of a system in synch with each other.
Chapter 2 illustrates a generic system development process for engineering requirements from a statement of needs and stakeholder requirements through to subsystem and components requirements. The same model is tailored to an ideal world view and one that integrates changes. Also a series of annotated v-models is effective in illustrating requirements and testing, requirements layers, enterprise requirements engineering and traceability and change management.
I also like that the authors are not wedded to any particular notation and have encouraged the use of a melange of common representations along with a few home grown ideas. The message is to represent (somehow) your understanding of a system so that it can be shared with others, improved and the details made traceable.
There are some examples related to business systems but the focus is mostly on technical engineering systems. However the principles are applicable to any kind of system in the largest sense of the word.
— Suzanne Robertson
This book at amazon.com amazon.co.uk Kindle edition

The first architectural patterns were published in the mid 90 by Frank Buschmann and his colleagues at Siemens. Since then a lot of other authors have contributed to the collection of architectural patterns, among them Martin Fowler, Gregor Hohpe as well as some more publications by the Siemens team.
With this volume 4 Frank Buschmann together with Kevlin Henney and Doug Schmidt have delivered a masterpiece: 104 patterns concisely characterized, well categorized and easy to understand. The collection starts with the most important patterns entitled „From Mud to Structure“. This section is followed by 12 categories of patterns, covering among others, distribution, event handling, concurrency, synchronization, object interac tion and modal behavior.
While some of the patterns are difficult to understand in their original publications here you can get to the essence in just 3 – 6 pages. And i fit sound interesting you are pointed to more information. So this book is like a distribution list to the collected wisdom for software architects covering more than a decade of research and practical experience. A must read for software designers and architects.
-- Peter Hruschka
This book at amazon.com

A group of experts has joined forces to publish this little 200 page book with „collective wisdom“ – as the subtitle suggests. The short essays are just 2 pages each. Many of the observations should be obvious to practicing architects. Alas – if you look around in industry – nearly all of these pearls of wisdom are neglected every day. Let me give you some titles to wet your appetite for reading more: „Chances are, Your biggest Problem isn’t technical“, „Seek the Value in Requested Capabilities“, „Challenge Assumptions – Especially Your Own“, „For the End User the Interface is the System“ „The Business Versus the Angry Architect“ and one of my favorites: „If there is only one solution, get a second opinion“.
This is a book that practicing architects should read once a month until they never think about ignoring this collective wisdom.
-- Peter Hruschka
Link to amazon.com

I was recently assembling a set of (Seville) rolling steel shelves for a storage area. The concept of the shelf connector was so ingenious that I found myself full of respect for whoever had designed it. I wanted to meet and shake hands with this admirable person. I suspect that crafting software for a living has given me — and maybe you too — some extremely strong feelings about design. We find ourselves exclaiming that “the iPad is elegant,” or “my DVR has a human interface which is positively opaque!” People from other fields probably have these feelings as well, but I sense that ours are much more deeply experienced.
The economic case for good design in software is all about testability, reliability and ease of adaptation to change. But your sense that the design of a given routine is either a thing of beauty or “the dog’s breakfast” probably has nothing to do with any of these factors. It’s much more likely to be all about style and elegance of concept. Oddly, style and elegance are two things that are distinctly absent from almost all texts on the subject of software design. Most of the classic texts are mostly about design notation and documentation.
Fred Brooks’ new book, The Design of Design, is the exception. Here the treatment is exclusively on what it is about a given design that makes us take our breath in in admiration or let it out in sad disgust. The book doesn’t teach us how to make great designs, but it does teach us how to think about the subject. Like everything else we’ve received from the extraordinary Fred Brooks, this book is a treasure.
— Tom DeMarco

This book lists a writer (Richard Luecke) but no author. Presumably, it has been assembled by members of the Harvard Business School Press. This shows as the book comes across as slightly stuffy and academic. That is the bad news out of the way.
The rest of the book is made up of practical advice. That is, advice for someone who wants to pick up some, and I stress “some”, innovation techniques. The book has a grab bag of techniques for helping you find new ideas.
That’s the first third of the book. The rest of it concentrates on the hard stuff, and this is where the book comes into its own. The hard stuff is getting the innovation accepted by the organisation and the marketplace. The tone is academic, and this is not aimed at cavalier entrepreneurs, but at anybody who wants to place a structure around his or her attempts at moving from the innovation stage to the production stage. This then is the strength of this book.
— James Robertson
The novel form of learning is not, er, novel, and this time out Austin and company have used it to great effect. You are carried along with their hero as he deals with open warfare in his department as he struggles to juggle conflicting demands with resources and risk.
The book is not all entertainment. Each chapter has a section at the end for reflections and lessons learned. I was tempted to read only these, but the Jim Barton’s days in the office were far too alluring.
— James Robertson



"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded." — Capers Jones
This book at Amazon
"This elegant and informative book is the follow-up to the Robertsons' Mastering the Requirements Process. It isn't very often that a reviewer finds he can't put a technical book down, but it happened this time. This book is the product of seriously good consultancy over "more than a quarter century"; and that is supported by beautifully clear writing, not to mention James Robertson's fresh and witty illustrations." — Ian Alexander

Karen Fisk, writing in The Maine Times contrasts DeMarco with author Evelyn Waugh: "DeMarco's pen is light, honest but indulgent. Whereas Waugh seemed to loathe his characters, DeMarco loves his." And so will you!

If There's No Risk on Your Next Project, Don't Do It. Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competition.
In Waltzing with Bears Tom DeMarco and Timothy Lister—the best-selling authors of Peopleware—show readers how to identify and embrace worthwhile risks. Developers are then set free to push the limits. Download a sample.



" . . . a charming and amusing tale about the triumph of lighthearted goodness over the forces of darkness. Never has a young man's loss of innocence seemed so sweet and touching. Expecting from the title yet another grisly thriller, I was enchanted to discover a sunlit ruin of a summer mansion, full of quirky characters pursuing hilarious private obsessions. I missed this book whenever I had to put it down, and rushed to get back to it."
— Lisa Alther, author of Kinflicks and Other Women

The overall purpose of this book is to present a broad approach to
the effective development of systems, especially those involving
multiple disciplines-as most systems do. We use a variety of practical,
real-world case studies to illustrate the nature of systems and the
system development process, and we include system models that can be
used in the process.
This book at amazon
This book at Dorset House Publishing

"Ever wonder why everybody at Microsoft gets their own office, with
walls and a door that shuts? It's in there. Why do managers give so
much leeway to their teams to get things done? That's in there too. Why
are there so many jelled SWAT teams at Microsoft that are remarkably
productive? Mainly because Bill Gates has built a company full of
managers who read Peopleware. I can't recommend this book highly enough.
It is the one thing every software manager needs to read... not just
once, but once a year."
This book at Dorset House
This book at Amazon


"A masterful job. . . . a thoroughly detailed case study." — Ed Yourdon
"Clearly the best book available for teaching modern systems analysis to practitioners." — Rich Cohen



"Das Buch liefert nicht nur zahlreiche Fakten, sondern ist auf Grund der vielen eingestreuten Geschichten aus der Praxis von Entwicklungsprojekten auch ein gut lesbarer Schmöker. Ein echter Lesetipp!" — IT-Business Magazin

Peopleware authors Tom DeMarco and Tim Lister combed through ten years' worth
of software magazines and journals and selected 31 of the best articles on software
issues.
This book at Amazon


"You can't control what you can't measure". DeMarco's seminal work on estimation.

