Authors: Justin Gehtland and Bruce A. Tate. O'Reilly, 2004, ISBN: 0-596-00676-4
The authors mention the Lewis and Clark expedition as a metaphor for something bloated that has to slim down to be successful. Can you think of some other metaphors from your own experience? Write about these on the WebCT discussion board for "BFSJ Reading Notes"
The writers focus on Java technology as something that has suffered from bloat. What else in the software world has become bloated?
The authors suggest that four things have driven the bloat:
They discuss each in more detail
In this section, the authors compare the bloat of writing a simple counter class using Enterprise Java Beans (EJBs) to the game played by the Cat in the Hat from the Dr. Seuss story called "Up Up with the Fish!".
You don't have to code this to see the point that the author is making.
As it turns out, most of the folks I talk to that are doing real-world Java-based web site development (UD Alums such as Luis Mendes, Stacy Lyvers and Jerry Heinz) are not using EJB, but are instead relying on the technologies described in this book: Struts, Spring, Hibernate. They are using tools such as Ant, JUnit and log4j.
I heard all these points from UD alums doing real-world development before I read this book. The fact that the book confirmed what people were telling me about real-world practice suggested to me that you would benefit from reading it too.
I was also influenced by the fact that the book takes controversial stands: for example, downplaying the importance of inheritance. The folks who study how college students learn are telling me that students learn more when they are given opportunities to confront controversies in their field and decide for themselves, instead of just being told "this is how it is".
This book is full of such opportunities.
Questions to consider when reading this section:
1.1.3 Economic Forces
This section refers to something called the Golden Hammer problem. One of the main things I hope this textbook will lead you to is a better understanding of the Golden Hammer problem.
If you are a " big fan" of Python, or Perl, or PHP, or XML, or LISP, or .NET or whatever, it could become your "Golden Hammer". Tou may think of every problem in terms of how it can be a vehicle to show what a wonderful tool your "Golden Hammer" is, and how much better "foo" is than "bar".
The Golden Hammer problem is a problem that happens in our own thinking, inside our mind. To solve it, we have to get better at observing our own thinking.
What are your own Golden Hammers? (both inside software, and in general)
The "Golden Hammer" problem will be a recurring theme in this book, so I save a more detailed discussion for later; for now, I just want to invite you to be on the lookout for this problem, both in software development, and in life in general. Anytime you spot an instance of it, write about it in the BFSJ reading notes discussion board on WebCT.
The authors credit Antipatterns, by William J. Brown, et al. (Wiley & Sons) with a description of this problem as it applies to software development. The term Antipatterns is another one we'll see a lot this semester.
The author offers five possible reactions to the bloat, and indicates that each one has a time and a place.
Note that once you leave school and are in the so-called "real world" in a software development job, it may be someone else (i.e. your manager) that is making the call as to which of these your organization follows.
Having said that, if you had any influence over the decision, which of these appeals most to you? That may tell you something about what kind of organization you want to be a part of after you graduate. Write about this on the BFSJ discussion board on WebCT.
This section is an overview of the five principles around which the entire book is organized. Each of the next five chapters is devoted, in its entirety, to one of these five principles. (That's chapters 2-6).
I want to invite you to look for these five principles in everything we do this semester. Discuss what they mean. Identify when we are following them, and when we are not following them.
This section provides a quick overview of each of these. We'll dive into each one in more detail in a later chapter, but its worth it to try to get the big picture of all five principles first.
One way to try to remember them, and also to check whether you really understand what the authors mean by them, is to see if you can restate the same five ideas, but without using any of the same words. For example, can you express what the authors mean by "Keep it Simple", without using the words "Keep" or "Simple"? (Its ok to reuse words such as "it", "and", "for".) Post your own version of the five principles on the BFSJ discussion board on WebCT. (Later in the semester, after we've spent more time with each of the five, we'll revisit this and see if you've found wording that you like better.)
So chapters 2,3,4,5,6 are the five principles. The rest of the book shakes out like this.
The author promises to "take his own medicine" and keep the book simple and short. So I'll end the Chapter 1 reading notes for BFSJ by doing the same thing.