“Rise and Resurrection of the American Programmer” by Ed Yourdon
A book that has been occupying my bookshelf from time immemorial and only now have I decided to give it a go. The title focuses heavily on topics such as project and management and offers a rich catalog of references to choose from on the subject.
This does not mean that the audience of this book is limited only to software project managers. In actuality, I believe every IT professional will find something for himself within this title. The book brushes against a wide array of topics and is a lovely pulp of software engineering practices bound loosely to one of its 13 chapters.
The book is a follow-up to its predecessor “Decline and Fall of the American Programmer” which I have not regrettably read yet. In the book author aims to correct the thesis he developed in its predecessor, that is that American IT companies were in danger of being outmaneuvered by their offshore counterparts. He however decided to correct this thesis due to factors such as the difficulties the offshore companies had when dealing with US and other Western customers and the American primacy in adoption of the nascent Internet technology. 23 years after the release of the book we may surely agree that it wise of the author to correct such a claim with American giants such as Google, Amazon, Microsoft and Apple garnishing most of the IT market.
The book may come across as quite dated and justifiably so as it was written in 1995 in the advent of the Internet when technologies such as Delphi, Visual Basic and Smalltalk rocked the marked. This however in my case turned out to be one of the book’s advantages.The content of this book made me realize that though the technologies, products and the general market in which they operate change, people and processes that govern software development don’t.
The 7th chapter of the book made the point exceptionally clear, covering the idea of “good enough software”. Having just finished a large project at my company which I could surely label as “good enough” the accuracy and actuality of the struggles in software development struck really close to home. The dilemma between providing user with the feature he wants, on schedule as the manager wants and with with as little bugs as your conscience desires is something every employee in technology will at some point face.
The book also surprised me with a quite lengthy chapter about embedded systems in which the author accurately predicts the development in the embedded systems and intelligent electronics sectors. The chapter also foreshadows the rise of home automation and intelligent home appliances which in the current IoT era have become readily available to ever increasing number of customers. It stunned me that the author could predict the development of this branch of technology nearly 20 years before it kicked in.
The remainder of the book is filled to the brim with observations on the state of the Software sector in mid 90s, a collage of topics, remarks and anecdotes on various areas of the software development such as peopleware, project management, best and worst practices, testing the software and more. Everybody will find a little chapter tailored just for himself I believe. There is even a chapter that provides an eagle eye view on the then-emergent Java technology which some people may find of interest.
Overall the book has proven to be quite a pleasant and enjoyable read, that I would highly recommend to everybody interested in some retrospective insight into software development management.
“The Mythical Man Month” (available to download — link at the bottom of the post) by Fred Brooks
“Look at my words, ye mighty and despair” one would say. Having read the book a strong cognitive dissonance remains. It seems that this book’s best qualities also happen to be its worst ones. This book is old, old indeed. Having been released in 1975 this book is to modern software engineer what the trilobites are to a biologist. None of the technologies or products mentioned in it are in commercial use nowadays. But despite that the book has managed to age reasonably well. It may be partly due to its structure — a loose collection of essays derived from author’s management experiences while working on big software products for IBM.
The focus of this book is not the software itself, but the process of developing it, which seems to be key to this books longevity. It describes each topic from a generic and process-oriented way which definitely helped it stand the test of time. You won’t learn from it the object oriented design, SCRUM methodologies or any similar stuff. What this book is ripe with however is common-sense approach to software project wrapped in a an approachable language. It contains many key phrases or metaphors that remain with the reader long after the reading is finished, like the famous Brooke’s Law: “Adding human resources to a late software project makes it later”, discussing nonlinearity of relation between programs functionality and the number of bugs it contains, or comparing software development of large tar pit into which the manager falls.
The book covers in a brief and coherent way issues such as people management, planning, testing and managing complexity in a large software project. It is a light read, and due to its convenient size can be finished in one afternoon. This and the cult status this book holds in some circles (and it is highly influential in the broader body of software development literature — it has been mentioned in both of other books covered in this reviews) could be reasons enough to pick it up.
If you are a manager in a software company familiarizing yourself with the title may bring some new ideas on how to manage your projects — the book holds many ideas within its 14 essay-chapters. Or you may just find comfort in finding out that the woes of managing a large software project are nothing new. As for the programmers, this book may be a good title for you if you want to familiarize yourself with issues your manager faces, get invited into the inner circle of people who have actually read this book, or just spend a pleasant afternoon with quality collection of essays. The world is your oyster.
#### “Clean Code” by Robert C. Martin
The final dish on today’s reviewers plate. The Clean Code is personally the book I have enjoyed the most out of this three. Though also it has been the most painful one to read. Not necessarily because of its superior length, but the extent in which the book aptly and swiftly makes one doubt his craftsmanship in code. I wish I had discovered this book sooner.
The main and basically only premise of the book is titular clean code. What it is, what it is not and how to achieve it. The book answers all of these questions. And it manages to do so without sounding preachy or judging the reader. It does so meticulously enough, with a decent introduction and discussion on the nature of good coding practices and the resultant clean or “good” code produced by them. Then it guides the reader through thematically scoped chapters, each covering a different aspect of coding like naming, formatting, class management and handling concurrency. Each chapter is wrapper densely with code examples showing both bad and improved cleaner code. This helps greatly in understanding the concepts and recommendations laid out in the book, it also makes the reader more active in the reading process as he has to compile and run code in his head (both the terrible one and the clean).
I feel that Java programmers have been given an unfair advantage in this book since all the code it contains was written in their language, but it does not mean that non-Java programmers will be left in the dark. The code is quite simple and can be easily understood by someone with minimal programming knowledge, though some Java fluency is certainly an asset. All the rules the book presents are universal enough to be applied to any modern programming language that at least pretends to have something in common with being object-oriented (even non-object oriented peeps will find something for themselves in this book I am sure).
The title is richly, but not extensively illustrated, the language used is simple and clear, which makes the title a light read, with the honorable exception of aforementioned code samples. The chapters are long enough to cover the topic, but not long enough to exhaust the reader. The book contains appendixes with a ton of code to analyze for the more curious readers.
I feel like the reception of this book will be biased depending on who you are. If you are a project manager that does not deal with the code itself I do not think you will benefit much from reading this book. If you are a moderately experienced or a senior programmer lot of the points in the books will probably seem obvious to you and the reading will only remind you a few rules or practices you probably already knew or disagree with.
However if you are a junior programmer or even just an aspiring CS student or hobbyist this book is a must for you. It covers many of the practical aspects of programming that are often omitted or bluntly not observed in the courses and other materials. It will make you aware that being a good programmer is not only measured by the pace at which you produce the code, but also by the quality of the code produced. I remember vividly when I prepared myself for the first programming job. I have been reading books about Java, Python, JavaScript, doing courses online. They taught me well how to manipulate on the collections, how to make a class inheritance structure in each of the languages, what the 4 principles of OOP are, what a singleton is, how to make a simple blogging page when you could publish your own posts. I taught I was ready. And then came the recruitment tasks in the form of the whole project. I was shocked and mentally mutilated by how bad my coding practices were. 50 line long undebuggable methods, unnecessary classes, iterating over collections many times too much. My code ha it all. I was disappointed in myself. I decided to practice more on my hobby projects and eventually my code and coding habits have improved. I wish however that I had read that book at that time. This book would not make me program better — that is what practice does. It would however have made me realize a lot sooner why my coding sucks. That knowledge is invaluable to anybody stepping into the craft of code development and is reason enough to pick this book up.
Thank you for reading the reviews, if you liked them (or the total opposite of that), please let me know in the comments below.
In the next post of Software Engineer’s Library I will focus on the more popular Python books.
Link to the Mythical Man Month:
