I've recently joined a technical book club and we are reading a book called "Making Software". I'm only about 20% done with it, but I wanted to test out this new HEY World thing, so I thought I'd give it a shot and write an early review of the book.
The book itself is very dense. Very academic. But reeeeallly interesting! Each chapter is done by a different research group and each one of them is about one particular topic in Software Engineering. They go over what we have (and don't have!) scientific evidence about. Things like:
The book itself is very dense. Very academic. But reeeeallly interesting! Each chapter is done by a different research group and each one of them is about one particular topic in Software Engineering. They go over what we have (and don't have!) scientific evidence about. Things like:
- We need more research on Agile practices. eXtreme Programming seems to be the methodology with more research compared to the other Agile methods. It seems to be easy to introduce and it worked well in a variety of different environments. They found the "onsite customer" practice to be unsustainable in the long term. There are studies on Pair Programming which shows that more complex tasks benefit on qualify from pairing, but at the cost of considerably greater effort
- The importance of qualitative research (combined with quantitative research), because we tend to see the field as "solely technical" and forget about the human factors of programming, estimating, managing, etc
- Bug distribution seems to follow a Pareto distribution: in general, 80% of the bugs seems to be caused by 20% of the code
- Syntactic complexity metrics cannot capture the whole picture of software complexity. These metrics (such as cyclomatic complexity) are exclusively based on the structure of the programs itself, or the properties of the text. They do not provide information on the effort needed to comprehend the code. Not more than lines of code do, at least. That's not to say they are "bad". Cyclomatic complexity is really useful to tell you how many paths on your code you need to test, for instance
- They also have a chapter on the impacts of intelligence, personality, and expertise on software development. Some interesting stuff:
- Intelligence is good for acquiring new skills, but not for predicting skills one has already acquired (which goes against some hiring practices that tend to measure IQ)
- They go over why it's not enough to "hire the best programmers". They compare it with airline disasters. It's not enough to hire the best pilots to minimize air disasters; you need safety measures in place, and the ability to work with others
- We don't get better at estimating just by doing it daily. We need more deliberate practices and exercises, but since software is so dependent on the ones doing it (different people can build different solutions to the same problems), it's hard to come up with such exercises
- We must take some time to reflect on our work daily. That lines up with a practice that I have been doing lately using Basecamp's daily check-in
As I said, I'm only 20% done with this book and there is more things that I haven't talked about here.
It's a really good one, but maybe too dense. I'm enjoying it a lot. It reads like you're reading a scientific paper, so it can get a bit boring at times (especially when they are describing their methods and how the got to their conclusions/numbers - which is really interesting too, but I'm here more for the conclusions. At least for now).
Anyways, I hope I can update this piece when I'm done with the book. Some of these notes were not yet discussed on the book club yet (we meet monthly), so I don't have peer-review on them. So take it with a grain of salt (or read the book yourself! It's a good one).