I read this book originally in college and then re-read it after a couple years of coding professionally. While there are certainly some dated sectionI read this book originally in college and then re-read it after a couple years of coding professionally. While there are certainly some dated sections, such as the idea of having the analog of a surgical team to code, many of the suggestions have held against the test of time.
The two most popular are "no silver bullets" and "adding developers to a late project makes it later." The former is that no new technology/technique will make an order of magnitude difference in productivity over 10 years ago. This is especially important when dealing with vendors or the latest proselytizer of a language or process ideology. I find this is a nice complement to Robert Glass's opinion that the biggest difference in productive teams is the quality of the developers. The second is more self-explanatory. The ramp up cost of adding new developers exceeds the value they will deliver within a reasonable amount of time.
There are also less referenced lessons to be gleaned from the book. For example, long before Agile, this book eschewed waterfall development in favor of an iterative approach. My favorite lesson in the book is that of conceptual integrity. In essence this is how Brooks refers to the idea that a piece of software should do one thing well and if it tries to fit many roles it will be a poor fit for all of them, instead of a good fit for one. As an example, he cites several Cathedrals that took centuries to complete. The Cathedrals that fell victim to egotistical architects in the middle or later stages of construction are less aesthetically consistent and therefore appealing than those in which the original style was respected.
Brooks also recommends keeping two independent career tracks for developers. In many organizations developers are forced into management after a certain level. Brooks argues this is a mistake and that in many cases it is better to let some developers stay developers. This requires title and compensation parity with the management track.
While many of the technology specific examples are dated, Mythical Man Month is a recommended read for every developer. ...more
There are two main lessons I gleaned from this book. The first is that the easiest way to produce successful software is to hirer the best software deThere are two main lessons I gleaned from this book. The first is that the easiest way to produce successful software is to hirer the best software developers you can acquire. Based on several studies listed in the book, the best developers are up to 30 times more productive than the worst developers. This make procuring quality developers the most effective decision in managing a software project. The second important lesson is the benefit of code being looked at by multiple people. This is not to be interpreted as one large code review with all developers once per quarter. Instead code reviews seem to be more beneficial with only a few developers, and done as frequently as possible....more
If one were to pick any GUI book to read, it should be The Humane Interface. Jef Raskin, credited as the creator of the Apple Macintosh Project, has lIf one were to pick any GUI book to read, it should be The Humane Interface. Jef Raskin, credited as the creator of the Apple Macintosh Project, has laid out a very radical view as to the shortcomings and successor of the WIMP interface. Though radical, his views are incredibly compelling.
Raskin recommends discarding the word intuitive when describing an interface. Raskin comments that the only intuitive interface is the nipple, all others are learned. In other words an interface is only deemed intuitive if it is similar to interfaces encountered previously, and thus habituated.
Along with habituation, Raskin's other tenet is the avoidance of modality, particularly message boxes and confirmation boxes. Message boxes leave the user with no choices and thus should not be modal and interrupt the user. Confirmation boxes simply confirm an action. Raskin argues it is better for the user experience to instead allow the ability to undo if possible.
Though many of his recommendations are radical, several of his ideas have appeared posthumously in new products from Microsoft, Apple, Google, and others.
The ribbon interface in MS Office and the exclusion of the personalized menus is an indication of realizing the importance of habituation and a reduction of modality. In the ribbon, menu items do not move depending on usage as they did in the habituation breaking personalized menus. Instead the items in the ribbon are no longer modal and are viewable while editing. While many users complained initially about the ribbon because it broke habituation from previous incarnations, it is definitely a more efficient interface in the long run.
The pinching on the Mighty Mouse was also a feature mentioned in The Humane Interface, as well as the ability to zoom via pinching that is found in the iPhone.
Though instrumental to the Macintosh project, Raskin eschews usage of the mouse because it is modal. It requires the user to shift their hands from the keyboard. Instead he prefers a text box that can interpret commands. This idea is found in the likes Quicksilver, Google Search Box, and even the Google homepage itself.
Definitely recommended for anyone designing user interfaces....more
A decent book that I found to be mostly review, and longer than it needed to be. All the obvious suggestions were included such as use short classes aA decent book that I found to be mostly review, and longer than it needed to be. All the obvious suggestions were included such as use short classes and methods, intention revealing names, etc. but there were a few principles that stood out. First is limiting constructor and method arguments to no more than four and preferably none. Next greenfield project I start, I am going to try and enforce this at the build level and see how it affects the design. Next is extracting methods/classes when they mix multiple levels of abstraction. This is a good heuristic to use alongside length and single responsibility when determining when to extract a method or class. The chapter on concurrency was disappointing. It made the suggestions of relying on immutability and abstracting away concurrency, but with no concrete examples of how such a thing is achieved, or how to test it....more
Metaprogramming Ruby is by far my favorite Ruby book. First, it does not treat the reader as a brand new programmer. The basics of Ruby are obvious toMetaprogramming Ruby is by far my favorite Ruby book. First, it does not treat the reader as a brand new programmer. The basics of Ruby are obvious to anyone that has programmed before, and can be picked up as examples are given. Thankfully this is not included in this book. What is included are the main differences between Ruby and other object-oriented languages such as Java, Python, and C++. This is an area which most other Ruby books completely lack.
If you are curious how Ruby pulls off it's magic (particularly if you are amazed at the tricks in Rails or ActiveRecord), or just wish to leverage Ruby's strongest features, then this is the book you want to pick up. If you are new to Ruby, but not to programming, start with Metaprogramming Ruby. It is much more succinct and useful (the summary of "spells" at the end of the book is gold) than the much longer The Ruby Way or Pick Axe.
Why not 5 stars? The author's boss-employee schtick to explain the concepts along with the excessive amount of lame nerd humor got a bit annoying and for me took away from an otherwise excellent read....more
Growing Object-Oriented Software shows the reader how TDD, done from the inception of a greenfield project, can have a dramatic effect on both the desGrowing Object-Oriented Software shows the reader how TDD, done from the inception of a greenfield project, can have a dramatic effect on both the design and correctness of a piece of software. The book covers not only unit testing, but also integration, and end-to-end testing, demonstrating that TDD is effective at every level of granularity. In fact, the examples of integration testing are the strongest aspect of the book, and read like natural language while exercising multiple parts of the system simultaneously, and additionally providing documentation about the system that unit testing often does not. Excellent object-oriented advice is also sprinkled throughout the book, such that -Impl suffixes and I- prefixes are meaningless and should be avoided for implementations and interfaces respectively (interfaces should refer to services, classes should refer to implementations). The distinction between objects and values, even though both are classes in Java, is also stressed. Instead of allowing for duplication in tests, several helper patterns are discussed such as the Test Data Builder. Lastly, while dependency injection is obviously favored, Spring containers are rightly eschewed.
There are a few parts of the book that could have been improved. First is that the authors are advocates of behavior-based over state-based testing. They do a good job of defending this position by advising to use as few expectations per test as possible, but I couldn't help but notice the duplication of the implementation of the code-under-test in the test itself, which would have been avoided with state-based testing. Second, while the authors support the idea of not mixing business and presentation logic and keeping the View as small as possible, they still felt it was worth using the complete real View in testing, and using timeouts to sync up with the GUI thread. Lastly, the book contains yet another attempt at testing concurrency without using message passing. This is particularly odd because the authors take the SmallTalk view that object-orientation is inherently about messages passed between objects....more
An excellent read countering popular notions that performing knowledge work correctly equates working at a breakneck pace. Instead, the author suggestAn excellent read countering popular notions that performing knowledge work correctly equates working at a breakneck pace. Instead, the author suggests it is beneficial to build in "slack" or free time to ensure that knowledge workers do not work at 100% efficiency.
The first section starts by showing how knowledge work is not like manufacturing. First, it is not easy to measure efficiency in knowledge work. This makes it difficult to measure the diminishing returns from overtime. Second, short of removing distractions, it is not possible to accelerate knowledge work. The brain works at its own rate, and thinking cannot be consciously hastened. Third, knowledge workers are non-fungible and therefore the cost of finding a replacement, due to attrition from overwork, and getting them up to speed, is quite high. Last, is that process does not work well with knowledge work as all it does is tell you how to do the easy part of knowledge work, and does little to solve the hard problems.
The second section covers middle management. The author notes that middle management are often the first to get cut, and asserts that this is a mistake. In fact it is important to keep middle management particularly "not busy" as most of the benefit of middle managers is that which comes from time that is unassigned. For this reason, it is also important to employ support staff as they cost less and allow the middle management to use their time more effectively.
The last section covers risk management. Slack is essential for risk management as risk inherently involves the unknown. Without a proper amount of slack, a failure can end up destroying a project.
Overall a worthwhile read for those in knowledge work....more
I finally decided to learn a console based text editor. I decided on Vim because it is a favorite amongst those that use ruby and go, and also Vi/VimI finally decided to learn a console based text editor. I decided on Vim because it is a favorite amongst those that use ruby and go, and also Vi/Vim emphasizes minimalism in contrast to emacs. Being a complete Vim/vi newbie I decided to pick up this quick guide to learn, if nothing else, of what the editor is capable. I found it to be an solid introduction and reference to the power of Vim for all but advanced users....more
A good read on tightening the feedback loop of development further than continuous integration. Most developers, or at least most I have worked with,A good read on tightening the feedback loop of development further than continuous integration. Most developers, or at least most I have worked with, run their unit tests at least once before they commit their code to source control. Ben takes the idea of tight feedback loops to the next logical step, by running unit tests on every save (obviously compile also if applicable for that language). This simple technique lets the developer know even earlier if their changes had adverse effects. The second technique shown was to checkout the latest code every time all the tests pass. This decreases the time between integrations. The book mainly concentrates on Ruby/Rails and JavaScript but the concepts are applicable in any language. Hopefully this technique becomes mainstream and becomes the default in popular IDEs....more
Loading...
