The book is very well organized with each fact and fallacy presented in the same format. First a discussion of the fact, next the controversy and finally the source(s) for the fact. There are 55 facts grouped into four categories; About management, About the life cycle, About quality and About Research. Which are conveniently the first four chapters of the book. The last three chapters are the categories for the 10 fallacies: About management, About the lifecycle and About education.
Chapter one is about management and it contains five subcategories; People, Tools and Technologies, Estimation, Reuse and Complexity. The facts about people are related to the information in Peopleware and The Mythical Man Month. These include “Adding people to a late project make it later” and “The working environment has a profound impact on productivity and quality”. The facts about tools aren’t too unexpected for instance “Software developers talk a lot about tools, but seldom use them”. The facts on reuse are worth reading particularly the discussions of reuse in the large.
The section on complexity contains an interesting fact “Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical”. I found this interesting since most people envision developers as someone sitting in front of a computer writing code all day long. Although I think this was more true before the personal computer it still has merit. I tend to design on the fly as I am coding, probably not the best practice, however, it is much more effective to take the time to create a good design document. This takes thought and some creativity in order to generate a good design. However don’t forget to keep up on your clerical skills.
Chapter two contains facts relating to the life cycle. Again these facts are grouped together under several subheadings. Since there are 22 facts in this chapter I thought I would highlight a few of them. Under design “There is seldom one best design solution to a software problem”, not much controversy here since there are several ways to solve problems. The single best solution is a very elusive beast and it may even be a waste of time hunting it down. Under error removal “Error removal is the most time consuming phase of the life cycle”, although this seems obvious we hate to admit that software can contain so many errors. We spend a lot of our time finding and correcting bugs during the software development process. In fact this process continues well after the software is released.
Although all the facts about testing have valuable insights “One hundred percent coverage is still far from enough” stood out to me. The premise here is that you can have a unit test which tests every single function in your code. You can also have tests that “press every button” on your application. However, you can never have a set of tests that calls every function in every way it can be called. A function can fail if a specific sequence of functions are called before it and replicating every possible combination is impossible.
Reviews and inspections get their own category, since this process can greatly improve code quality and functionality. The one fact that stood out for me was “Postdelivery reviews (some call them “retrospectives”) are important and seldom performed”, probably because of my Army background and its use of After Action Reviews (AARs). It is very important to look back on a project and determine what went well and what can use some improvement or even be eliminated the next time. Hindsight is 20/20 after all.
The section on Maintenance is a must read. Maintenance is the biggest portion of software development, not only fixing bugs but adding new features can be considered maintenance. If I had to pick one fact it would be number 43 “Maintenance is a solution, not a problem”. By fixing bugs we make the product more stable and reliable. We can also discover inefficiencies during the maintenance process adding to the performance of the product. By adding new features into the scope of maintenance you can easily justify spending most of your time and efforts doing maintenance.
Chapter three focuses on Quality. I discussed fact number 46 in an earlier post but I think fact number 47 “Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability” deserves a closer look as well. Although all of these things look like elements of a quality product they are in fact something different.
User satisfaction = Meets requirements + delivered when needed + appropriate cost + quality product.
Since quality product is included in user satisfaction then these two things must be separate. Each of these items is very important since user satisfaction is generally what keeps you in business. Therefore it is important to address all of these items. Quality itself is only one of the elements of user satisfaction and is defined by its own attributes outlined in fact 46: portability, reliability, efficiency, usability, testability, understandability and modifiability. The rest of chapter three goes into more detail on these attributes of quality.
Ten fallacies are discussed in the final three chapters of the book. The two that stood out to me were “You can’t manage what you can’t measure” and “You teach people how to program by showing them how to write programs”.
The ability to measure developers is somewhat elusive. Programming is a very creative process making it very difficult to quantify neatly. Besides that programmers are generally very intelligent people who can figure out how to game any measurement technique. Joel Spolsky wrote a great article on what motivates developers and demonstrates the fallacy of motivation through measurement. This along with Robert Glass’ discussion really demonstrate the fallacy of management through measurement.
The last fallacy “You teach people how to program by showing them how to write programs” seemed more of a fact to me until I read the discussion. Essentially we don’t learn how to write in our native language before we learn how to read. We have to understand how sentences are constructed and how we relate them together before we are expected to write on our own. However, in the programming world we read a tutorial, insert your language of choice here, which starts with “Hello World” and moves into more complex tasks quickly. Before even reading a well designed program you are required to write a Twenty Questions Game. You can learn a lot by reading good and bad code as well as writing your own code. So perhaps the way we learn written language could be applied to learning programming as well.
The bottom line: If you have actually made it this far you can probably tell that I enjoyed the book. Robert Glass spent a lot of time collecting information for all his facts and fallacies and providing opposing viewpoints for most of them. I found his insights interesting and relevant to the discipline of software development.
No comments:
Post a Comment