Next up on the “Must Read” list is the follow-up book from Martin Fowler of the Gang of Four, Refactoring: Improving the Design of Existing Code. I hesitated with this one for a bit, thinking about adding it to the “Should Read” book list rather than the “Must Read.” I did this because, for many experienced developers, the topics of this book are going to seem elementary. Anyone decently experienced is going to look at a section header such as “Changing a Reference object to a Value object” and think “why I am even wasting my time with this Programming 101 refresher?” But, much like Design Patterns, the fact that much of the information in the book has already been deduced through a combination of ingenuity and experience does not mean that the refresher cannot be extremely valuable. And not ruffle any feathers, but usually the people that are most dismissive of “refresher” material are exactly those that need it the most! <g>
At the very least, this book is an encyclopedia of these changes, and while many or most of the changes will be elementary, even the sections on those changes might have a new insight or viewpoint that the developer has not considered. Chapter 3, which I’ll discuss below, is particularly useful here. Another benefit is that any development manager or mentor of younger developers would be well-served to be familiar with this book so that they can point their less experienced colleagues to the proper place to learn how to correct mistakes they have made.
Like Design Patterns before it, this book is about more than just specific techniques for one language. The advice for guidelines and techniques in this book can be applied across all object oriented programming. It’s a common viewpoint to dismiss refactoring as a problem that you only encounter in projects involving legacy systems. That’s not really the case, though, as it is common to see these types of problems in daily work when interfacing with different systems, reviewing the work done by less experienced developers, etc.
The first 50 pages are a good introduction to draw someone in, as it provides a walkthrough of a standard refactoring problem. This is a great read for the inexperienced programmer, as it can be an enlightening view into the daily problem solving in the lives of senior developers and architects. The next chapter makes a case for refactoring, which can be interesting for some, but doesn’t hold a candle to Chapter 3. Chapter 3 is 20 pages of gold, as it examines the “Smell” of problems in need of refactoring. When confronted with a specific problem, it’s easy enough to know the solution. This chapter focuses on how to identify problems that are present. This is really a brilliant piece of writing, in that it is clear cut, with obvious warning signs on what to recognize to diagnose the problem.
The next chapter, Building Tests, focuses on an area that we frequently don’t do enough of. It focuses on JUnit, but the testing focus, as with the patterns and coding elsewhere, can be applied to other languages. The other chapters, again, exactly like Design Patterns, group the common techniques and problems into common areas and then proceed through each of them in a very straightforward matter. At the very least, the book makes a fantastic reference to keep around and to thumb through when you run into problems you can’t quite put your finger on, or when you’re just looking for a great refresh of some standard material.
My library of books should have a wing dedicated to Steve McConnell. He’s a great writer, in that he discusses technical issues with an approachable style and a practical outlook. Much like Peopleware, he’s looking for things that can be proven to work, not just treading out the same axiomatic fluff that eventually becomes mantra because it’s repeated so many times. To give you an idea of the impact his books and articles have had, in 1998, he was named alongside Bill Gates & Linus Torvalds as the one of the 3 most important people in the software industry by Software Development Magazine.
Today we’re going to focus on Rapid Development, mainly because it ties in so well with my previous blog on Peopleware. Rapid Development is all about how to manage a program or a project. It was written after his book Code Complete, which you can expect to see showing up in this blog shortly. Code Complete focuses on the day-to-day practice of how to code and techniques to employ, while this book focuses more on the software engineering aspect, looking at methodologies and practices that work and don’t work, and why.
Early on in the book, McConnell hits you with some of the “Classic Mistakes”, and this is sure to make you wince if you’re fairly experienced. One of those winces for me was the “Overly Optimistic Schedule” (see my blog on this mistake). Some of them won’t evoke such bad feelings, though…you might even get a little boost from memory of how you successfully navigated one of them. For me, that one was the classic mistake of uncontrolled problem employees. I don’t know that I actually solved the problem myself, but I don’t wince because everything turned out great. You can read about it HERE.
As an aside on hiring, I’ll point out that many people don’t realize that a bad hire doesn’t just “not help”…it actually hurts. The wrong employee doesn’t just contribute at a rate lower than others, they can actually have a negative overall contribution to the team. Think about all of the time invested in a person training them up, having weekly meetings with them, and how much time their mistakes take other people time to fix. And then figure up all of the motivation and momentum that the “wrong” person can suck out of a team. Someone that is incompetent or negative can completely sidetrack a team as they devote energy to dealing with them. Too often, though, the belief is to just “fill the spot” with a candidate that’s less than stellar. This lack of recognition of the value of each and every team member on a software team often shows the need for management to clue in and read one of the other “Must Read” books, Peopleware.
Other classic mistakes that I’ll point out is the “overestimation of savings from new tools and technologies”, which goes hand-in-hand with the “Silver Bullet Syndrome.” Both are related to human nature in that we always try to look for just one thing that will be the huge productivity boost the manager desires. It’s not sexy to realize that you’re not going to get a 30% productivity gain from the application of one thing, like the latest version of Visual Studio, or moving everyone to the cool new language/library, or implementing Agile (especially given how many “Agile shops” are anything but Agile!), etc. Large productivity gains are the combination of doing 1000 small things correctly, and then implementing the right changes that continue to build upon the base you already have. But again, it’s human nature to always expect a little more, so not only does Steve McConnell cover this, but Dr. Fred Brooks (author of The Mythical Man Month) also wrote up a short treatise about it. You can find “No Silver Bullet” easily with an internet search, and it has also been reprinted in later copies of The Mythical Man Month. I’ll cover it in a blog here in the near future, as understanding accidental versus essential complexity is a key skill as a software designer.
And to build on this idea of how 1000 small things must be done well for great productivity gains, McConnell devotes the last section of the book to be an encyclopedia of software best practices. Well, it’s actually better than an encyclopedia because it breaks down and correlates each of the best practices to specific problems that it solves and trade-offs or issues that it might cause itself. It’s not that you need to go and do every single one of these gains, it’s that you need to be aware of what you’re gaining from choosing a particular best practice, and what you might be losing or conflict you might be creating as well. And the key to remember is that this isn’t written for the programmers specifically. We’ve got enough books on “how to get better programming”, such as McConnell’s own Code Complete, the Gang of 4’s Design Patterns & Refactoring books, etc. This is written for management and senior development to determine the best way to plan for development. This is a software engineering book, which is why I said up front that it goes hand-in-hand with a book like Peopleware. You’ll even see some overlap, such as both recommending taking advantage of The Hawthorne Effect. Highly recommended.
For obvious reasons, the names and specifics will be left out, but the lesson will remain. I was brought in to advise a product team on the right architecture and tools for their next generation product. I met a highly competent team that had been together for a long time, to the point where it wasn’t uncommon for everyone on the team to head to dinner or to watch a game together. It was very close knit, and management had invested heavily in everyone.
Management was also heavily invested in the future. The current product was going to be completely revamped, and contracts were in place that required this. So when 3 of the 7 members on the development team privately confided that the new product was a pipe dream and that they believed it would never work, you can imagine how seriously I took this! And it wasn’t just the normal gripe: in some cases it was outright rebellion with undone work items, returning “it’s not possible” findings on relatively simple research tasks, and talking the future of the company down to even those that believed in what they were doing. I found out about this because the positive members complained to me in confidence, saying it was really bringing them down.
My plan was pretty straightforward. I approach everything with a high degree of transparency, so I first talked to 2 of them to see if I could get them to “get on the bus” and at least open themselves up to this. This was a disaster. One of the members, I’ll call him The Pessimist, flat out told me that it wasn’t going to work, and that things would be better off if they would just quit dreaming. I talked to him about the contracts and how this wasn’t really optional for his company, and he was fairly nonchalant about it, but adamant that he wasn’t going to change, and that the sooner everyone realized this for the failure it was, the better. The second one agreed to an attitude change, but it was obvious that this was just an attempt to be a team player, as the negativity still crept in at every possibility.
Part 2 of the plan was to go to management. Within 2 weeks of my initial suspicions, I had informed management of just how serious this problem was. I shared with them articles about problem employees, talked to them about possible remedies, and I found out that one of the managers went back for years with The Pessimist, and that even having a “hard” talk with The Pessimist was farther than they would be willing to go. He was family, and they were settled just pulling his dead weight rather than having to lose a member of the family. But as with most things in consulting, when the first attempt fails, but you know that you’re right, you try & try again.
The first strategy was to separate the 3. They were working together a lot and forming a cluster of negativity, so we worked on finding them tasks that didn’t overlap, and that had them working with the other, more positive employees. The third member literally turned around just on that. Within 2 weeks, he was enjoying what he was working on and it completely turned around. Within the month, our second grumpy employee was happy as well. By giving people the ability to pick areas they were working on, the second employee threw himself into support of the old product. A month in, he had gone from a 60-40 split to nearly 100% on the older product, and he loved it. Everyone else moved their responsibilities for the previous version to him, and he kept learning more about a product he loved. Problem #2 was solved, as long term support for the previous product was going to span years, and he was happy being “the guy” for Tier 3 support and new features for the old product. Only Mr. Pessimist remained.
This problem was solved in the 2nd month. I had 2 very “strong” talks with management about how a change needed to be made, and I hit the wall with them. I was sure they would never be able to even put Mr. Pessimist on notice, let alone be able to fire him without improvement. His productivity was down and he was still loading down the team. And then he resigned. Call it Deus Ex Machina, but it was based on him getting tired of working with people that didn’t share his same beliefs. He simply packed up his ball and went home. Now this left a particularly bad taste in my mouth at the time. Not because it wasn’t good for the team that he left, but that I had failed to give management the “proof” they needed to make a change. I’ve since learned that people make bad decisions for bad reasons all the time, and that you’re not going to win every battle. But the good news is that the team replaced Mr. Pessimist with another good contributor, and within 18 months the new software was released. The contracts were satisfied and everyone was happy.
Best of all, management talked to me and said that they now “got it” with regards to the problem employees. They admitted to knowing it was wrong, but they hadn’t really seen “how wrong” it was until the change was made. But they had learned the lesson now, and understood what team dynamics meant. In retrospect, I likely should have come up with some mechanism to isolate Mr. Pessimist outside of the team for a couple of weeks, either an offsite, or training, or some “deep project” that he could do at home. That likely would have been enough to show the difference in attitudes and productivity when he returned, but hindsight is always 20-20! Again, you can’t win them all, but it’s fun to try.
In August 1998, we had just shipped Visual Studio 6.0, and I was sitting in a room with my peers when the guy in charge of all of Visual Studio, having recently been poached from Borland for what was rumored to be a 7 figure payout, told the room that we would be shipping Visual Studio 7.0, which later came to be known as Visual Studio .Net, in less than 12 months.
Yes, I said that right. In less than 12 months, a completely new runtime using 1 completely new language (C#) and 1 re-worked language (VB.Net) would be running in a brand new, consolidated IDE. Previous versions of Visual Studio might have looked like they were in the same IDE, but they weren’t. There was a core framework in place for some products, but the older guard products were still running in a shell that was primarily developed for them, but made to look like the standard IDE.
When our new leader showed us the schedule, it was met with a few gasps, a few laughs, and a lot of stunned silence at just how patently absurd it all was. The runtime at that point was a mess, and not due to be consumable for months. Much of the other work hadn’t even started yet, and the team was just coming off of a ship cycle where they had released 2 versions in the previous 18 months. 1 row up for me, a manager I recognized pretended to light up an imaginary joint, then took a hit and offered to pass it down the row. When someone looked at him puzzled, he said “You should have some of what they’re having.”
Realistically, 18-24 months made a lot of sense. We were about 6 months away from the team having worked on the .Net runtime nearly a year, and around that time it was starting to become useful. The IDE and all of the associated libraries, wizards, and controls couldn’t really start until after that milestone was achieved, so another 12-18 months to sort those out would have been right on par with previous versions of Visual Studio. But new leadership, particular when a new leader just came in with a high price tag, wants to flex some muscle, so we got a schedule that was impossible.
The result? Visual Studio .Net shipped in late 2001, nearly 2.5 years late on a 12 month project. And it wasn’t that it needed nearly 4 years to ship, it’s that the overly aggressive schedule up front caused all sorts of problems long term. No one wanted to admit that the schedule was that wrong, and so there were a series of “micro-slips”, rather than accurately judging things again and giving the project the extra 6-12 months that it really needed. And yes, I’m overgeneralizing to an extent here, but this was a major problem on the macro level.
Want to know something else crazy? Windows had made the same mistake from 1996-1999, during the project that eventually became Windows 2000. But that’s a story for another day….
This book is the 2nd book that any software manager should read (The Mythical Man Month being the first), in my humble opinion. Ok, not just in my opinion, but in Fred Brooks’ as well. He wrote the Mythical Man Month and has said that Peopleware deserves every bit as much credit as his book.
Its brilliance is also highlighted by the fact that the failings it addresses are so commonly found. In my experience, the most common failings of management are usually explained by a lack of understanding the human aspect of employees. This manifests itself in a lot of ways, everything from a poorly laid out workspace that doesn’t allow employees to concentrate to how the best managers protect their employees from the typical corporate politics while the worst ones don’t. And it’s not just their opinions. Everything is backed up by studies and metrics used to analyze and separate the good from the bad. And it’s for more than just developer-type organizations, as the real focus is on how to manage those that need to be creative for their occupation. So if you’re running or plan to be running an organization focused on creativity (e.g. software development, consulting, writers, artists, etc), then is absolutely required reading, and now rather than later.
The goal of any organization should be productivity. I know, I know…this seems like a no brainer, but when looking at the facts we have organizations that focus on short term gains and constantly do things that can be proven to hurt productivity. And while we have smart things like Agile trying to approach the productivity problem and what can make it better, these measures don’t come close to addressing how to optimize the work environment. This is what Peopleware is all about. The book is extremely approachable, in that every chapter is relatively short (less than 10 pages on average) and they each focus on a specific topic. Here are some examples:
The first 6 chapters & 34 total pages are devoted to the differences between trying to manage a manufacturing focused job versus how to manage creative types. It discusses the truth behind Parkinson’s Law (“The amount of work will expand to fill the time allotted to it”), the overlap between ridiculous productivity gains claims and medicinal scams, and a host of other interesting topics.
The next 7 chapters and roughly 60 pages focus on the office environment, which are some of the most straightforward and easy to make changes that exist for companies today. Then we have 4 chapters for a total of 29 pages focused on hiring the right people, what to do with them once they get there, and how to avoid the high hidden costs of turnover. You’ll learn about Horatio Hornblower, how hiring a juggler isn’t very different from hiring a developer, and how to build a self-healing system. It is absolute gold in less than 30 pages, with at least one new idea every other page.
The book finishes with sections on how to increase productivity and how to make work fun, which is one of the keys to increasing productivity and cutting back on turnover. This really is one for the ages.
The Last Lecture or John Ousterhaut’s “Renaissance Man” Lecture Notes
Either of these should have the intended effect, but The Last Lecture is more tragic. I’ll deal with it first.
The Last Lecture is a common speaking series where great speakers give what they feel would answer the question “What lecture could you give that you would feel good if it were your last action on earth?” Randy had cancer that was going to kill him when he did this. He knew that his treatments weren’t working and he was dealing with the last few “good” months of his life and what he wanted to do with them. This is a tough subject for me, as I’ve had to deal with this several times in the past few years with family and friends.
If you don’t recognize the name, Randy Pausch was a fairly well-known computer scientist at Carnegie Mellon, responsible for some fantastic work such as ALICE. If you’ve never used ALICE, I highly recommend it (or whatever replacement is out there for it now, as it has been a few years since I had reason to use it). It’s a programming tool for kids, with the specific goal of teaching the basics of logic and organized thinking in a “fun” way. It introduces kids to computers and programming by having them build videos or interactive stories. I’ve been involved with summer camps that use it, and can attest first hand to how it resonates with kids. It’s “fun” like a game, but they’re learning great skills that will help them throughout life while they’re doing it.
So there is a video for the Last Lecture out there, and it’s definitely worth watching. Some of it is clichéd, but that’s to be expected. The key for me, and why I recommend this, is that the exercise of evaluating what is truly important to you and what might you might want to do before you check out is important. At Microsoft, we used to have yearly evaluations that, if done correctly in a competent group, really pushed you to expand your skills and horizons. The Last Lecture was a reminder of those days and pushed me to re-evaluate what I had let die on the vine that I really didn’t want to.
Along those same lines, John Ousterhout’s Operating System Lecture Notes did the same thing for me. Dr. Ousterhout is known primarily for developing Tcl (“tickle”) and the Tk Toolkit, a scripting language I used in college for user interface design. The notes will be tough to find (for example, I couldn’t find them on a recent search), but I’ll try to discern the basics here. I doubt I will say it as inspirationally, but I’ll try:
Don’t be the person that sits in front of the computer all day. Go out. See the world. Do what you dreamed about as a young child, just to see if it measures up to your dreams. Develop skills that have nothing to do with computers, and try to be a polymath, i.e. a “Renaissance Man/Woman”, a la da Vinci, Michelangelo, or Francis Bacon. These experiences and skills will help you with your job in ways that you never expected.
From my own experience, I can say that my experiences travelling have made me a much stronger architect and team member. Most software teams are an international mix of talent, and my experiences with different cultures while travelling has helped me to relate to my team members and they’re shared experiences. I have been consistently taught the lesson that these different perspectives, when properly applied, will lead to better quality software. Different people see and perceive things differently, and you can use these different perspectives to evaluate your own ideas and designs. You’ll be amazed at what you’ll learn and how much better you can make your stuff when you’ve seen it through the eyes of others. The issue is that you’ll need to have a real connection with these people to get the type of honest feedback you need. For me, it’s talking to them about their homeland and food. For you, it might be discussing art, language, history, music, movies, or culture with them.
In addition to these added perspectives, you’ll also learn that many of these hobbies or pastimes will teach you lessons about life that can be applied to the workplace. And I realize that I’m getting very clichéd here, but we as computer scientists don’t tend to have the best interpersonal skills, so any practice we have dealing with people in these outside activities can always be helpful.
Ok, notice this isn't a "Must Read", but it's a very good one!
The Design of Everyday Things
So maybe you’re finding yourself doing a lot of design. If that’s the case, then I recommend this book. It’s not a home run like some of the others, but it is extremely helpful for getting your mind into the right frameset for design, as well as having some useful examples of great designs and what makes them so. I should say that I don’t actually agree with every design decision this book makes, but maybe that’s because I need a few “Learning Experiences” myself!
The real problem with design, in my opinion, is that people look at their designs just like they view their children: they’re as convinced that they’ve just designed a great UI as they are that their baby is cute. You know what I mean: for most people that wheel out the baby pictures, it doesn’t matter how wrinkly, hairy, or scary the child looks, they’re convinced that they’re showing you a vision of beauty. It’s the same with their designs. It doesn’t matter how obtuse, how obscure, how unusable the designs are…they’re convinced of its superiority.
A quick example: last year I was evaluating if we were going to take over a software project for a client. As part of the discovery, I met with everyone from the team and we talked about the problems. Most of the stuff was classic bad management and unrealistic expectations, but the one thing that was truly scary was the design. They had fallen into the problem of “dueling designers”, where management wouldn’t step up and name one person the “Design Czar” to own the design. Much as having too many architects can destroy a project, having too many designers can as well, and that had clearly happened. It had actually devolved to the point where management was picking different pieces of the designs and the software ended up looking like this sort of Frankenstein’s Monster of patched together UI.
What I expected to find was that there were 2 good designs that had been butchered, but that wasn’t what I found. What I found was 1 solid, clean design, and 1 fairly intensive, overly complex design. It turned out that the second designer had been a major user of a similar software package, and had designed the “perfect” UI to accomplish certain tasks as quickly as possible. I have no doubt that, in any test that would measure the amount of time necessary to do certain repetitive tasks, the second design would be extremely efficient. But a design is much more than the sum of a few efficient actions, and this one fell down quickly when looking at the whole. It would have been familiar and usable for the users of the competitive package, but not for any new users, which was a primary stated goal of the project.
So what was the point of going off on this huge aside? That the second designer followed the advice of many design books: look at the primary actions and then optimize them, but he never seemed to consider the entire system as a whole. And that’s really what good designers do: they don’t dive into the weeds and make a “pretty” screen. They look at EVERYTHING that the system will entail, and come up with an overarching design metaphor that will work across the system. There can be other metaphors used elsewhere, but a great design is not accomplished by optimizing atomic actions. It’s accomplished by determining what the atomic actions are and then determining the best way to present those to your majority of your users. The Design of Everyday Things is a great book for getting you to think about those issues.
Simple, elegant, everyday examples of some advanced concepts such as designing signals, designing for expecting errors, and understanding your constraints.
This is the book written by the Gang of Four that should be required reading for any developer or architect. The vocabulary alone that it imparts makes it worth reading, but it’s also another “a-ha” type book. I can guarantee that any of you with any significant coding experience will have used some of these, possibly without even having realized it. But reading it is still useful due to the large amount of information and thought starters contained regarding each design pattern.
This book, simply put, is a great start for understanding the basics of object-oriented program & reuse. The 23 patterns contained in the book are common and widespread. While you might not use some of them if you stick to a particular area of development, anyone with a broader set of development experience should run across all but a few within a handful of years. Each design pattern is laid out clearly using the same format as well, with the following sections:
4. Structure Diagrams
5. Participants, i.e. the members
6. Collaborations, e.g. the calls and requests
9. Sample Code
10. Known Uses
11. Related Patterns
There are several benefits to using these design patterns in the possible places. The first is that patterns serve as the basis for potential reuse of designs and architectures. And we’re not talking about reuse of a design that you’re hashing out in different scenarios, we’re talking about patterns that have stood the test of time and been thoroughly tested. This means that the results from the design pattern will be superior to a newly created design you have little experience with, which should lead to less re-work as the requirements change, an unfortunate common occurrence in our line of work. Let’s also not discount the vocabulary mentioned previously. There is a lot of value in being able to recognize and understand other designs and architectures quickly through the recognition and application of these design patterns as abstractions. This also allows us to quickly relate designs and architectures to other through this common vocabulary and understanding of these core patterns.
Now that we’ve talked about how great it is and what types of things you can learn from it, let’s talk about what you DON’T need to ever do. The first is to glorify any of these books, and this one especially, as some sort of religious equivalent. And some people do for this particular book. It’s not hard to find people with dog-eared, marked up books, part of the aftermath of having analyzed parts of the book 100 or more times, including poring over passages and trying to determine exactly what was meant by a certain phrase. This, frankly, is taking it MUCH too far. This is definitely a great book to read because, as mentioned above, you’ll run into these all during your career. I’ve also found it helpful to go back and read over sections when it’s been years since I’ve applied a pattern I’m about to use again. But it’s never to follow the items here as gospel. It’s always meant as a thought starter.
The second abuse of this great book is that junior architects will make a point to try to turn EVERYTHING into a design pattern. This just overcomplicates things. As mentioned in The Design of Everyday Things, a good UI design is usually achieved through the clear application of 1 clear metaphor, and it is a clear comparison to the number of patterns used in the case of a technical architecture. So most likely, the best technical architecture will be made by choosing an overarching pattern for a particular component, and then involving others only where the complexity really warrants one.
The third common abuse is that people try to follow the patterns and, in particular, the rules laid out in the book about those patterns to the point where the project is harmed. We can also see this when the incorrect design pattern is applied to a problem, which leads to the even more complexity and overhead. Remember, your job is to create the best software that you can. And that has everything to do with being flexible and delivering the right product at the right time and next to nothing to do with following the academic advice of what a proper pattern should look like.
This is Dr. Fred Brooks’ seminal work for project management and software engineering. This cannot be highly recommended enough, and it should be the first book that any project manager, software manager, or development lead becomes acquainted with, in my humble opinion.
Why to read it:
Quite frankly, this will be the “a-ha” book for anyone with some experience in software development. And given its age and the number of low-level maxims that it’s able to convey, it really is more of a primer than an advanced study. But I’m sure that something you’ll read in it will bring about some sort of disagreement, and let’s call these “learning experiences.”
And the best part of all is that this book is management friendly! Yes, this is the book that you can recommend to the manager in your group that just “doesn’t get it.” It’s short, large print, and simply written. It has helped countless managers realize the issues with their behavior in the past, and it can help your situation, as well.
Just a small sample of the multitude of useful maxims that this book teaches:
1. The Mythical Man-Month
This is the eponymous maxim that is at the core of the book. The idea is you can’t say “if it takes 1 person 5 months, it will take 5 people 1 month.” Now in more extreme examples, i.e. “1 person 100 weeks versus 100 people for 1 week” it might seem obvious, but you will quickly run into a manager or lead that will suggest that they can throw a person or two into a project for a brief amount of time to help you “catch back up” on the timeline. This is fool’s gold, as it completely ignores the time the team spends ramping this person up, the communication overhead that is increased by adding another member to the team, etc. This would be a legendary book if it only covered this point, but it does a lot more.
2. There is no silver bullet
This cannot be said often enough. There is no one single strategy, tip, or trick that is going to make everything work well. That’s not saying that a new strategy (such as Agile) can’t address multiple problems. What it is saying is that you can’t rely on that strategy to solve everything. There will always be other things that can be done to squeeze better productivity out of the team, and the good manager will look at all of these. You can also find this “No Silver Bullet” concept discussed and explained in a paper published by Dr. Brooks on the internet.
3. Great programmers write code that a college kid can maintain
Uh oh. A few of you probably bristled, but this is one of those “Learning Experiences” mentioned above! We all know people that optimize code to extreme measures, sometimes to the point where the code is practically unreadable. It’s almost as if the complexity is some badge of honor to be shared only among the worthy. This, however, is one of the worst things you can do for your clients or the product. The simple fact is that at some point, likely sooner than you think, someone else will own the code you’ve written, and struggle to maintain it. Instead of showing off your intelligence by making it unintelligible, strive to make it clean and simple. The ability to break problems down to their simplest components, and then design neat & clean interfaces between those components is not highly valued enough in our industry. The real geniuses are the ones that can code up systems that any idiot can own, because eventually some idiot will! And yes, I pilfered that line nearly directly from Warren Buffett, but he was speaking about business and managers.
4. An architect’s second system will be the most bloated design they ever do
If you don’t believe this, go work with some college grad students. It’s great to work with them because they’re enthusiastic, soak up info like a sponge, and are very sharp. However, the systems that they design can leave something to be desired. They get so caught up in the possibilities that they design around everything, and before you know it you’ve got 9 layers of abstraction when 1 or 2 would do, and way more code maintaining that overhead than should have gone into the project to begin with.
And the basics of documentation, core release events, proper communication, and a lot of other good stuff!
Why not to listen to those who tell you not to read it:
The common criticisms I’ve heard are this:
1. “This isn’t an “a-ha” book, it’s stuff you already know.”
Hmmm, maybe. If you’re experienced with several projects under your belt, you might be checking these items off as things you’ve already learned through experience, but it’s more likely that you were working with someone that DID know this book and was teaching you the lessons organically. And even if you know the lessons, you should read it for the different perspectives on the problems presented, and so that you can properly recommend it to the managers you’re working with that have clearly NOT read it. How do you recommend a book you’ve never read?
2. “The tools and advice it mentions are outdated.”
This is the worst criticism, b/c it’s missing the forest for the trees. Brooks’ team was using assembly language and talking about things like investing in your library, whereas today 90% of projects are created using a library from a 3rd party or service from another team. In other words, the details don’t always apply directly to current situations. This isn’t what you should be reading this for, however. Look at the human nature involved. Look at the “obvious” things that turn out to be proven incorrect. They deal with similar examples to the maxims of today (i.e. “Many eyes make bugs shallow”) that have been completely disproven, so the historical perspective is interesting. So explore the concepts, not the details. And again, the managers that you’ve recommended this to will be looking at the concepts, so they’ll likely be getting the necessary lessons.