"A Pragmatic Approach" focused on principles that are applicable to any and all software development. It was a bit more specific than the prior chapter. Unfortunately, it's been a while since I actually read the chapter, so we'll see. I may also be finding it difficult to summarize the chapter because it was a collection of tips rather than having an overarching theme.
Regardless; onward.
"The Evils of Duplication" explained why duplication was such a pain in the ass - basically, DRY, or "Don't Repeat Yourself." I loved this quote from this chapter:
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Thinking of code as knowledge really captures the human element behind lines of code.
Anyway, back on topic, the chapter goes through a few of the reasons behind why a software developer might be tempted to duplicate code: imposed, inadvertent, impatient, and interdeveloper duplication. The four I's of duplication, I suppose. Regardless, the answer is to stay DRY.
If you have a single, unambiguous, authoritative representation of knowledge, or code, within a system, it is easier to reuse, easier to change, easier to share between teams.
"Orthogonality" is the word for when two variables or inputs do not affect each other. For instance, your car's turn signal is orthogonal to whether or not you actually turn, otherwise you would probably end up sideswiping people on the road, making 90° turns on the highway, etc.
By eliminating side effects in your code, you gain a lot of benefits and reduce risk. There are a lot of benefits to orthogonality, so I highly recommend reading this chapter.
"Reversibility" is probably the chapter I understood the least. The basic idea is that anything you do should be reversible. I think the reason I'm confused is because this applies more to project or strategy level decisions and is only secondarily reflected in code. The examples that the chapter uses are being locked into using certain third party vendors, which is a situation I have experience with in my work at Aggrego. The decisions to use the vendors were not reversible - we gave up too much to them without keeping data or architecture decisions in our own hands.
I'm glad I decided to summarize this. I feel like I understand it better now.
"Tracer Bullets" talks about a minimalist approach to development, basically building skeletal code that provides a minimum of functionality. Then you can go back and get feedback on whether or not the result was desired and shift accordingly. These are evolving frameworks that are intended on being used in production eventually.
As opposed to "Tracer Bullets," prototypes are disposable code, mostly just pieces of different things that are glued together to provide a preview of what an experience might be. Use these when you need to validate that something will work at all before devoting a significant amount of time to developing it for real.
Domain languages, or domain specific languages (DSLs), are miniature languages that are particularly well suited to describing solutions for certain problem domains. Rspec, for example. DSLs are handy for sticking close to the language in the problem domain. This increases readability and maintainability. I think that as long as the problem domain doesn't change too much, the DSL shouldn't, either, making maintaining the mini language a minor task.
I also had trouble figuring out what the authors were saying here, since it started with a question about estimating bandwidth and I assumed it would be talking about project estimates. Which it did, actually, now that I'm flipping back through it. The bandwidth seems to be mostly a non-sequitur.
But there were some good points about estimating projects. For example, the units you use matters. Telling someone the project will be done in 13 days gives them the idea that it may be 12-14 days, whereas telling them it may take around two weeks gives them the idea that it may be anywhere from 1 to 3 weeks.
Otherwise, "iterate the schedule with the code" summarizes the chapter.
~
I made a mistake in taking so long between reading the chapter and summarizing it. I definitely lost some details. I shan't make the same mistake again.