Book Review: Writing Solid Code by Steve Maguire

4 out of 5 stars.  

This is an MS(!) Press book written by Steve Maguire in the early 90s. Why am I reading it now? Jim Weirich (of Rake fame) recommended this book in an online video that I happened to watch. 

The book was targeted at teams working in C ( distilled from the authors stint at Microsoft )... but the advice is pretty relevant even today if you can breeze through the code snippets. It seems to be out of print but you might luck out and find an old copy like I did

• Lean on the compiler.. turn on all the warnings by default. Disabling should be the exception not the rule.
• Use SCA tools from Day1. Fix issues regularly instead of letting them pile up.
• If you have unit tests, use them.
• Maintain a fortified debug version of your product with 'dev/debug mode asserts'. Conditionally compiled so that release version is lean.
• Use asserts to identify 'things that should not happen' as early as possible. (Of course tests are much better :)
• Reviewing the code (personally at least) before committing changes is the easiest and cheapest way to reduce bugs.

Design

• Don't create 'candy machine interfaces' - make it hard for clients to make mistakes.
• Eliminate 'undefined' behavior.. so that clients do not depend on it
• Don't bury error codes in return values - make them hard to ignore
• A function should do only ONE thing and do it well - (actually I rephrased it. this line's from Clean Code)
• Don't use flag arguments.
• Do not tradeoff client code readability over ease of implementation.. make code legible at point of call.
• Avoid sharing/Passing around global data
• Don't tradeoff global or algorithmic efficiency for local efficiency
• If you have to look it up, it isn't obvious. Make it boring and obvious.
• Eliminate as many if branches as possible.
• Write code for the "average" programmer. Simple over clever.

Attitude (IMO The best section of the book)

• Bugs just don't go away.. track them down.
• Fix bugs now.. not later
• Don't meddle with legacy code if you don't need to
• Don't add features if you don't need to. All flexibility has a cost. (maintenance, testing, learning curve, etc.)
• Don't keep trying solutions till one works. Take the time to find the correct one. Don't TRY.. READ.
• Don't rely on testers to find your bugs. Don't shoot the messenger when they do find your bugs
• Never allow the same bug to bite you twice. Fix your process to stonewall that type of bug.

The book has aged quite well over 20 years. Combined with on topic anecdotes (multicoloured screwdrivers is a keeper), this one is a good book to casually read while you wait for something to complete/load.


Note: The highlighted sections indicate Steve was agile before it became cool/a buzzword.

Lean Startup Book Review

Rated 3/5



The book is written in lucid manner with lots of anecdotes thrown in to illustrate the point being made. That said I'd have liked it to be concise (the essence could easily be extracted to a couple of blog posts)


I did a small experiment. Extracted out things that I felt were important take-aways and tried to see if it is something that I didn't know before (highlighted Blue).

• What over How. Deciding what to build is the crucial and more difficult problem (tip of the hat to Mr.Brooks)
• Validate your value hypothesis and your growth hypothesis. (Fail fast, regular demos, real customer, et. all. The growth angle was new for me)
• Cohort Analysis, Split testing
• Build Minimum Viable Product ASAP, Establish baseline, Tune, Validate.
  
• Metrics must be Actionable (demonstrate clear cause and effect), Accessible (simple, unambiguous, unrestricted), Auditable (verifiable - ability to test data on demand against reality)
• Reduce batch size , Reduce WIP, Pull model (Lean)
• Growth engines (the best part of the book IMHO)
• Sustainable growth = new customers result from the actions of past customers.
• Sticky: engaging customers for long-term. KeyMetric: Churn rate = Rate of acquiring new customers - attrition rate
• Viral: Not word of mouth. Referral a natural outcome of using the product. Revenue is usually indirect. KeyMetric: Viral co-efficient. How many referrals does a single new customer beget? > 1 indicates growth.
• Paid : Revenue invested to acquire new customers. Keymetric: Revenue over lifetime of customer - Cost per customer Aquisition
• It's usually a human problem. Ask 5 whys - answers usually go from technical to human issues. (Gerald Weinberg)
• Retrospectives: 
• Be tolerant of all mistakes
• Never allow the same mistake to be made again
• Shame on us for making it so easy to make a mistake.

Review : Growing Object Oriented Software - Guided by Tests: Freeman, Pryce

Recommended... best book on TDD in a while.

Just finished this one today... I got to fess up - that I am a "classicist". I've seen some real spaghetti tests involving mocks.. But I've gotten some periodic tension from the people on the other side of this religious fence of TDD. Since this book comes from "the torch-bearers of the mockist camp", I picked up a copy and tried to keep an open mind. And I although I haven't switched camps.. I now see the light. There is no one right path but the authors have placed some industrial strength beacons on this path and teach you how to use mocks and interaction tests to "grow" applications driven by automated tests. (However I still maintain that in untrained hands, Mocks (like C++) can be very dangerous and quickly lead into tarpits. Easy to abuse. However in the right hands, they can be used to write very expressive code & enable rapid and iterative development. ).

Some of the key takeaways for me were:

• Developing outside-in ATDD: writing a 'walking skeleton' first , spotting objects and roles (relationships) between them, TDDing these objects and "folding them back" into a running app was a new method to me.
• Listening to the tests, Focus on readability, tests with helpful diagnostics / failure messages, eliminating or reducing the irrelevant part of the test, use of builders + drivers to keep the tests concise
• The chapters on threads and asynchronous testing are home-runs. Don't leave for work without it. The last third of the book was worth the price of the book (It isn't yet available in India so had to get it from overseas).

There is a lot of real world knowledge that the authors have distilled down to a kind of 'secret sauce'.

Object Thinking

The book. Author: David West.

Remember Alan Kay's quotes that 'Object revolution is yet to come' & 'C++ wasn't what I had in mind when I coined the term object-oriented'? Now I'm no fanboy so I set about objectively looking at the matter presented in this book if there's any meat behind the argument 'You're all not getting it'. I read this book twice.. the second time trying to distill ideas that are innovative or new or unknown to me before I read this one.

There are n solutions to a single problem. All of them right in solving the problem however only a few extend the existing system at a 'natural joint' i.e. where it is consistent with the original structure/intent or theory of the developer. Such changes lead to systems that are easy to take-down and reassemble when you hit a dead end.. (along the lines of the Lego Brick metaphor, if you find that a brick doesn't give you the shape you want, you just chuck the brick and plug in a different shape.) This in fact is the bulb moment behind the XP practice of 'Metaphor'. Identifying the right set of objects and the distribution of responsibilities among them to suimulate a real world scenario is the sign of a master object designer. This book will not make you an artist but will give you some good pointers nonetheless.

• The first few chapters help the reader understand between the culture difference between 2 camps of 'scientific logical method-driven designers' and 'heuristics-driven artistic social designers'.
  
• Chapter 3 outlines the 4 fundamental tenets of object oriented thinking.
  
• Chapters 4 n 5 throw some light on the terminology and subtle thinking differences.
  
• Chapter 6,7,8,9 are the 'How-to'/actionable chapters.
  
• Chapter 10 is just bizarre... disjointed
  

The book as a whole doesn't exhibit 'flow'... something feels off.
The book definitely could have been shorter to make a better impact- I liked a bunch of ideas like Object Cubes (an extension to the CRC Card) as a thinking tool (I don't think I'll be building any physical cubes), the 4 presuppositions of object thinking, 'All inheritance must be based on behavior extensions', the little 'Behind The Quotes' sidebars , 'Object as a person' metaphor. Self-evaluating rules, Event Dispatchers and the DataItem type (as opposed to passive data) are interesting. That said it is a refreshing change to read about the craft behind OOP. 4 out of 5 stars

Agile Estimating and Planning - Mike Cohn

Book

Key take-aways from this book..

How to use something that sounds as childish as 'story points' and make it work better than the traditional GANTT chart sequential task based model ? Separate size from duration.
How to prioritize stories or themes ?
How do you know and explain Story#1 is 'more value to the customer'?
How to separate stories into must-haves / linear / exciters ?
How to plan releases and iterations ? How to track em ?
How to make an estimate of initial velocity and how to get better at it with iterations under your belt?

In short this was my missing piece of the agile jigsaw. Gonna read it again soon when I plan something new.

Recommended Read. Recommended Buy.

Essential .NET (Don Box + Chris Sells)

A bit terse but a treasure trove of .NET internal knowledge nonetheless. I finished the book last weekend. (Okay I cheated in the last 2 chapters). Security just went over my head and my intense passion for building heterogenous (COM, unmanaged and managed ) social (every module goes across the boundaries where the dragons be) systems (and pulling my hair out) led me to surf right over the last Interop chapter.The other chapters were quite enjoyable and I would recommend it to almost anyone, who is commited enough to unboxing the occasionally cryptic text. Also sometimes (read in the last 2 chapters), I felt that they were running out of pages and tried to stuff in as much as they could.
Assembly resolution, Interception and the CLR type system were real eye-openers. The figures in the book really help the prose.
All in all a great book.

What next?? I got another "Essential" book ( I love pain !) - Essential XML I'm gonna frag you too !!

Extreme Programming Adventures in C#

Ron Jeffries
ISBN 81-7853-088-0. 500 pgs / Indian edition available

I completed my run thru a couple of days back. Since I purchased this book, I feel I am entitled to a a review (which I am always). So here goes..
Ron's style of writing is nice... technique sprinkled with good humor. In this book, Ron is new to C# and needs an XML editor for his web site (Xprogramming.com - which is also good). The book is the result of these circumstances. So Ron places you on his ear and lets you peek while he goes about writing an XML editor, tailored to his needs while simultaneously practicing XP (okay so he cheats once in a while but who doesn't. As I found out, it's pretty tempting when you don't have a pair and you suffer from 'Let me see if this hack would work!'.
The sublime moral that Ron drops on you every now and then is that it is okay to not have a detailed design upfront, rather get a rough working model and keep chipping till you are done. (And you are done when all your tests run! XP Explained - 'XP Yoda' Kent Beck). This approach along with periodic reflection and refactoring gives much better results.
I tried this with a problem in Ruby (this should be my next post) and I am happy with my work.
As a chronic whiner, I felt that the "Undo" chapters don't seem right where Ron is faced with a design-breaking XP story. I'll have to re-read those once again.

All in all **** stars, pick this up - should have a lasting effect on the way you code.