I took a job as a programmer at the Naval Research Laboratory, working for astronomers who needed someone to write the code that would analyze the data coming back from the experiments that they flew on satellites and spacecraft. The first day on the job they showed me a sheet of FORTAN code and said “we want you to learn this.” It turned out to be the most fun thing I had ever done, and I went back to grad school and changed my major to computer science. I ended up as the Lanh and Oanh Nguyen Endowed Chair of Software Engineering in the Department of Computer Science at Iowa State University.
I wrote
Software Product-Line Engineering: A Family-Based Software Development Process
Brand starts off by exploring structure in architecture. Not only does he identify the six key structures in buildings, but he tells us how rapidly they change.
Never have I met or heard of a software architect who could predict for me how rapidly the structures that he/she uses to design and build his/her system will change. (Many can't even identify what the key structures in their systems are).
Brand then gives us lessons in what kinds of buildings undergo what kinds of changes, and how to build in a way that encourages or discourages change. He shows how owners modify their buildings over time, and how buildings evolve as they pass from one owner to another.
Structure, designing for change, and understanding the possible evolutionary paths that your construct may take are all topics that should intensely interest software engineers.
Buildings have often been studies whole in space, but never before have they been studied whole in time. How Buildings Learn is a masterful new synthesis that proposes that buildings adapt best when constantly refined and reshaped by their occupants, and that architects can mature from being artists of space to becoming artists of time.
From the connected farmhouses of New England to I.M. Pei's Media Lab, from "satisficing" to "form follows funding," from the evolution of bungalows to the invention of Santa Fe Style, from Low Road military surplus buildings to a High Road English classic like Chatsworth this…
This book shows what it takes to create a new science or field of technology.
At the start, no one knows what questions to ask or what experiments to perform. There are only indications that something is wrong with the current view of the field. No one knows what are the right variables and how they should be measured. (Sound familiar? Tell me, what is the software production capacity of your company?)
Over time, an explanatory paradigm appears and we can quantify and create theories on which to base predictions. The period of chaos between the early stages and the creation of theories is marked by the rise of the new paradigm, and a shift in the way of thinking. Are we in the midst of such a chaotic period?
Certainly we could use a paradigm shift. Kuhn doesn't tell us how to do it, but he does tell us what the signs are that we have made the shift.
A good book may have the power to change the way we see the world, but a great book actually becomes part of our daily consciousness, pervading our thinking to the point that we take it for granted, and we forget how provocative and challenging its ideas once were-and still are. "The Structure of Scientific Revolutions" is that kind of book. When it was first published in 1962, it was a landmark event in the history and philosophy of science. And fifty years later, it still has many lessons to teach. With "The Structure of Scientific Revolutions", Kuhn challenged long-standing…
Whereas Kuhn shows us the signs of new paradigm creation, Malcolm Gladwell, in this book, shows us how ideas spread.
This book is not just useful on the grand scale for spreading a paradigm shift, but also on small scales to spread new ideas about virtually anything, such as how your company should use particular tools or techniques, a particular process, or even why other developers should use your design.
An introduction to the Tipping Point theory explains how minor changes in ideas and products can increase their popularity and how small adjustments in an individual's immediate environment can alter group behavior.
How does one go about designing buildings and other things that we use every day?
Want to be an architect and create objects that are used every day?
This book will help you understand how to do that. If you are creating software, this book will define principles that will be useful to you in the design of your software.
First, businesses discovered quality as a key competitive edge; next came service. Now, Donald A. Norman, former Director of the Institute for Cognitive Science at the University of California, reveals how smart design is the new competitive frontier. The Design of Everyday Things is a powerful primer on how--and why--some products satisfy customers while others only frustrate them.
If you would like to know how children learn language and how it develops in their (and your) minds, then this book will interest you.
It will help you understand better what language is and how you use it. It will also help you to understand better how to help your children to learn and use language.
'Dazzling... Pinker's big idea is that language is an instinct...as innate to us as flying is to geese... Words can hardly do justice to the superlative range and liveliness of Pinker's investigations' - Independent
'A marvellously readable book... illuminates every facet of human language: its biological origin, its uniqueness to humanity, it acquisition by children, its grammatical structure, the production and perception of speech, the pathology of language disorders and the unstoppable evolution of languages and dialects' - Nature
Successful software engineers develop software that is widely used and involves many variations. One can think of a successful software system as a family, where all members of the family have certain elements in common, and each family member is a particular variation of the family, defined based on the variabilities allowed among and defining family members. This book defines a software family and describes how to think about the commonalities and variabilities that define the family.
I come by my interest in history and the years before, during, and after the Second World War honestly. For one thing, both my father and my father-in-law served as pilots in the war, my father a P-38 pilot in North Africa and my father-in-law a B-17 bomber pilot in England. Their histories connect me with a period I think we can still almost reach with our fingertips and one that has had a momentous impact on our lives today. I have taken that interest and passion to discover and write true life stories of the war—focusing on the untold and unheard stories often of the “Average Joe.”
October 24, 1944, is not a day of national remembrance. Yet, more Americans serving in World War II perished on that day than on any other single day of the war.
The narrative of No Average Day proceeds hour by hour and incident by incident while focusing its attention on ordinary individuals—clerks, radio operators, cooks, sailors, machinist mates, riflemen, and pilots and their air crews. All were men who chose to serve their country and soon found themselves in a terrifying and otherworldly place.
No Average Day reveals the vastness of the war as it reaches past the beaches in…
October 24, 1944, is not a day of national remembrance. Yet, more Americans serving in World War II perished on that day than on December 7, 1941, when the Japanese attacked Pearl Harbor, or on June 6, 1944, when the Allies stormed the beaches of Normandy, or on any other single day of the war. In its telling of the events of October 24, No Average Day proceeds hour by hour and incident by incident. The book begins with Army Private First-Class Paul Miller's pre-dawn demise in the Sendai #6B Japanese prisoner of war camp. It concludes with the death…
