Book: A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware

Notes and thoughts on the book with one of the longest titles ever, so I'll refer to it as "HP Laserjet" from now on.

BY the time I got to read it, I had been aware of this book for a while as it's not exactly new. It never really attracted my attention as it focuses on systems that I was never involved with. This changed recently (past two years) and after purchasing Industrial Devops I made the connection to this book again due to a mention in a promotional post for Industrial Devops.

The TL;DR for this book is that it's worth a read: it reinforced some convictions I already had, and went a bit in more depth on others. In both the HP Laserjet book and Industrial Devops I felt the part about certifications was notably absent. Since that's usually an expensive, delicate part of physical products design, I am perplexed at the fact that it's not covered in more depth.

Another remark is that some aspects that are strongly highlighted in this itrevolution newsletter entry are not (IMHO) pushed as strongly or described clearly in the book. I felt instead as if hey were left for me to read in-between lines.
This is perhaps my biggest gripe with the book, as I certainly feel these two approaches (one code base without #ifdef, and the extensive use of emulators/simulators) are exactly the engineering ingredients that allowed the HP team to engineer a solution to their productivity problema, as opposed to hiring their way out of them. I find that not covering them in more details makes a disservice to the engineers first, and the book second.

Anyways, here are the parts of the book that I felt were worth highlighting and writing down so that I could better interiorize them.

Notes

Don't hire (spend) your way out of a problem, engineer a solution!

6 principles:
  1. KISS/reduce overhead or waste
  2. don't overfill your plate
  3. cater tot the bottleneck
  4. integrate early and often
  5. find your planning rythm (sprint length)
  6. practitioners should define agile/lean practices
Always demo code that has been fully integrated into trunk (if it's not into trunk, it's not done)

Don't manage by metrics, instead use them to have conversations

Simple, clear priorities:
  1. P1: drop everything
  2. P2: next sprint
  3. P3: whenever
Align with marketing/sales

When making changes, work to minimize the disadvantages. The advantages will be naturally delivered by the change anyways, but the disadvantages might kill the change.

Focus on developer productivity:
  1. common dev environment
  2. simulator
  3. common test framework
  4. best HW you can afford, i.e.: 30" display, headsets, fast computers, etc

Popular posts

A not so short guide to ZFS on Linux

Image
Updated Oct 16 2013: shadow copies, memory settings and links for further learning. Updated Nov 15 2013: shadow copies example, samba tuning. Unless you've been living under a rock you should have by now heard many stories about how awesome ZFS is and the many ways it can help with saving your bacon . The downside is that ZFS is not available (natively) for Linux because the CDDL license under which it is released is incompatible with the GPL. Assuming you are not interested in converting to one of the many Illumos distributions or FreeBSD this guide might serve you as a starting point if you are attracted  by ZFS features but are reluctant to try it out on production systems. Basically in this post I note down both the tought process and the actual commands for implementing a fileserver for a small office. The fileserver will run as a virtual machine in a large ESXi host and use ZFS as the filesystem for shared data.
Read more

Indexing Apache access logs with ELK (Elasticsearch+Logstash+Kibana)

Image
Who said that grepping Apache logs has to be boring? Sample of dashboard that can be created with ELK. Pretty impressive, huh? The truth is that, as Enteprise applications move to the browser too, Apache access logs are a gold mine, it does not matter what your role is: developer, support or sysadmin. If you are not mining them you are most likely missing out a ton of information and, probably, making the wrong decisions. ELK (Elasticsearch, Logstash, Kibana) is a terrific, Open Source stack for visually analyzing Apache (or nginx) logs (but also any other timestamped data).
Read more

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in
Read more