Monday, August 23, 2010

Book Review: Facts and Fallacies of Software Engineering

image

Having this book on my shelf for quite some time now, I finally decided to to make my way through reading Facts and Fallacies of Software Engineering written by Robert L. Glass. As the title already implies, this well-established author lays down 55 facts and 10 fallacies about software engineering based on his half a century experience in the field.

The facts are divided in four categories: management, lifecycle, quality and research. The fallacies are split into three categories: management, lifecycle and education. Each of these categories have their own more specific sub-categories in which these facts and fallacies are classified. This way its easy to pickup the content about a particular topic of choice. Although I read the book from cover to cover, it isn’t required to do so. All facts and fallacies can be read on their own but occasionally the author refers to the discussion of other facts/fallacies in the book.

All facts and fallacies are laid down using the following structure:

  • The fact/fallacy itself is presented and discussed.
  • After which the controversies about a particular fact/fallacy are presented.
  • Finally, a list of books and articles are enumerated that were a source of information regarding the fact/fallacy. Some of these sources are ancient, some are more recent.

Here’s the list of facts:

  1. The most important factor in software work is the quality of the programmers.
  2. The best programmers are up to 28 times better than the worst programmers.
  3. Adding people to a late project makes it later.
  4. The working environment has a profound impact on productivity and quality.
  5. Hype (about tools and technology) is a plague on the house of software.
  6. New tools and techniques cause an initial loss of productivity / quality.
  7. Software developers talk a lot about tools, but seldom use them.
  8. One of the two most common causes of runaway projects is poor estimation.
  9. Software estimation usually occurs at the wrong time.
  10. Software estimation is usually done by the wrong people.
  11. Software estimates are rarely corrected as the project proceeds.
  12. It is not surprising that software estimates are bad. But we live and die by them anyway!
  13. There is a disconnect between software management and their programmers.
  14. The answer to a feasibility study is almost always "yes".
  15. Reuse-in-the-small is a solved problem.
  16. Reuse-in-the-large remains a mostly unsolved problem.
  17. Reuse-in-the-large works best in families of related systems.
  18. Reusable components are three times as hard to build and should be tried out in three different settings.
  19. Modification of reused code is particularly error-prone.
  20. Design pattern reuse is one solution to the problems of code reuse.
  21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
  22. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
  23. One of the two most common causes of runaway projects is unstable requirements.
  24. Requirements errors are the most expensive to fix during production.
  25. Missing requirements are the hardest requirements errors to correct.
  26. Explicit requirements 'explode' as implicit requirements for a solution evolve.
  27. There is seldom one best design solution to a software problem.
  28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
  29. Designer 'primitives' rarely match programmer 'primitives'.
  30. COBOL is a very bad language, but all the others are so much worse.
  31. Error removal is the most time-consuming phase of the lifecycle.
  32. Software is usually tested at best to the 55 to 60 percent coverage level.
  33. One hundred percent test coverage is still far from enough.
  34. Test tools are essential, but rarely used.
  35. Test automation rarely is. Most testing activities cannot be automated.
  36. Programmer-created, built-in debug code is an important supplement to testing tools.
  37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
  38. Rigorous inspections should not replace testing.
  39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
  40. Reviews are both technical and sociological, and both factors must be accommodated.
  41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
  42. Enhancements represent roughly 60 percent of maintenance costs.
  43. Maintenance is a solution-- not a problem.
  44. Understanding the existing product is the most difficult maintenance task.
  45. Better methods lead to more maintenance, not less.
  46. Quality is a collection of attributes.
  47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
  48. There are errors that most programmers tend to make.
  49. Errors tend to cluster.
  50. There is no single best approach to software error removal.
  51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
  52. Efficiency stems more from good design than good coding.
  53. High-order language code can be about 90 percent as efficient as comparable assembler code.
  54. There are tradeoffs between optimizing for time and optimizing for space.
  55. Many researchers advocate rather than investigate.

And the list of fallacies:

  1. You can't manage what you can't measure.
  2. You can manage quality into a software product.
  3. Programming can and should be egoless.
  4. Tools and techniques: one size fits all.
  5. Software needs more methodologies.
  6. To estimate cost and schedule, first estimate lines of code.
  7. Random test input is a good way to optimize testing.
  8. "Given enough eyeballs, all bugs are shallow".
  9. The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.
  10. You teach people how to program by showing them how to write programs.

Although this book has been published in 2004, the topics that are discussed in this book very much apply today and probably many years to come. I personally got the most from the facts about people, estimation, testing and maintenance. I really enjoyed reading this fascinating book and I encourage you to pick it up as well. Awareness of these facts and fallacies, whether you agree or disagree with them, is the first step to improving our craft.

Wednesday, August 18, 2010

Book Review: Debug It!

image

Throughout my career as a professional software developer,   I’ve spent quite a lot of my learning time to sharpen my debugging skills. I’ve always considered this as one of the required abilities of a true software craftsman. I also strongly believe that the time spent hunting bugs should be minimized as much as possible. Other required disciplines like Test-Driven Development should prevent using your debugging skills as much as possible. But when the shit hits the fan, being able to fall back on solid debugging skills is essential for any software engineer.

Long time readers of my blog know that I’m a huge fan of John Robbins’ books on the same topic. So when Paul Butcher, the author of Debug It!, asked me to give his book a read, I wholeheartedly accepted. And I’m very glad I did.

Most people automatically think about their favorite debugger tool when they hear or speak about “debugging”. This is not what this book is about. This book is about the intellectual process of fixing bugs. Just as Red-Green-Refactor, debugging is a discipline with its own core process.

The book is divided into three parts, each of which shines a light on a specific aspect of debugging as a whole. The first part both provides an overview as an in-depth explanation for each of the steps in the debugging process.   

imageFor more experienced developers this might just be a recap of the process they already know and follow. For less experienced developers, this first part provides a treasure of information that many of us have learned the hard way throughout our career.

The second part talks about how debugging fits into the wider software development process. Topics like bug tracking, dealing with users/support staff, prioritizing bugs, software quality, etc. … are discussed in the two chapters that constitute this part of the book.

The third and final part is composed of a number of more ‘advanced’ topics. A number of strategies are discussed for dealing with special cases like patching, concurrency bugs, Heisenbugs, performance bugs, bugs in third-party software, etc. … . There’s also a chapter that describes the ideal debugging environment, basically evangelizing automated tests, source control and automatic builds which are pretty basic things for most of us but unfortunately not everyone. The chapter on self-debugging software was quite interesting as well as the final chapter on anti-patterns which is also highly recommended. I was personally intrigued by the author’s take on maintenance teams, which reinforced my opinion on the matter (this might be a future blog post). 

This book also contains a vast number of anecdotes and short stories about real-world scenarios that help illustrate the different topics and enforce the points that the author tries to make.

Again, this book is highly recommended as it contains a whole lot of wisdom and experience from the field of software engineering. It’s only 190 pages, so you should be able to get through very quickly. So, you can’t lose on this one.

I know that I’ve been posting a lot of book reviews lately. I’ve been enjoying a quiet three week vacation at home so I’m making a futile attempt to catch up on my reading. I’ll probably have one or two more book reviews coming up.  

Wednesday, August 11, 2010

Book Review: Object-Oriented JavaScript

image

A good number of folks have recommended me to pick up Object-Oriented JavaScript after I put out this book review on JavaScript – The Good Parts. They told me that it’s a great way to dive into the guts of JavaScript, and I must admit that they were right. When I come to think about it, this has probably been the best book on learning a new programming language I have ever read before.

I’m not particularly a day in, day out web developer, but I have been using the JavaScript language a couple of times throughout my career. Over the last couple of years I’ve become fascinated by some of the JavaScript libraries that have been popping up. The most obvious ones being jQuery and ExtJS, but the rise of JavaScript outside the browser like node.js and the use of JavaScript in some NoSQL databases  like CouchDB seems like a very interesting evolution.

Reading this book only added to my fascination for this wonderful dynamic programming language. The nice thing about this book is that it thoroughly explains all the concepts of JavaScript throughout the different chapters. It starts by describing some language element, providing a clear high-level explanation and further expand throughout the rest of the chapters if necessary. This way the reader doesn’t get overwhelmed by all the details of a single particular language feature all at once.

The first chapter talks about the history, current state and future directions of JavaScript. It’s a nice overview of the evolution of the language. This chapter also provides a quick rehash of the basics of object-oriented programming and compares the OO concepts of JavaScript with other programming languages.

The second chapter provides the basics of the language like variables, data types, arrays, loops and conditionals.

The third chapter is all about functions, starting with basics and then more advanced stuff like anonymous function, self-invoking functions and inner functions. The chapter concludes with a superb explanation of closures in JavaScript.

The fourth chapter introduces objects. This chapter explains properties, methods and the various ways on how to create objects. After that, there’s an overview of the built-in objects (which are handled more in-depth in one of the appendices).

The fifth chapter is completely dedicated to the concept of prototypes. The author clearly explains the purpose of the prototype property and how to augment built-in objects.

The sixth chapter discusses a various number of ways to implement inheritance in JavaScript,  like prototype chaining, copying properties, prototypal inheritance, etc. ….    

The seventh chapter talks about JavaScript in a browser environment. Things like the BOM (Browser Object Model), DOM (Document Object Model) and events are discovered more in depth.

The final chapter shows a number of coding and design patterns in JavaScript. This chapter is definitely worthwhile to have a sense of some techniques used in modern JavaScript libraries like namespaces, public and private properties/functions, chaining, etc. …  

Chapter five and six are the ones that provided the most value for me personally. The explanation of prototypes and the various ways to implement inheritance in JavaScript were a real eye opener.

In short, this is the book you want to have lying around when programming and/or learning JavaScript. For me, this is JavaScript explained in the most understandable way possible.