Preface

Ever since I started writing software code—over two decades ago, but it feels like just the other day—I’ve wondered whether I’m doing it the “right” way. I still haven’t figured out what the right way is—but I’m sure that I’ve done software development in plenty of wrong ways.

When I created my first BASIC program for a college project many years ago, it was a long list of “spaghetti code” hundreds of lines long, with no separation of concerns. (Although object-oriented or service-oriented programming didn’t exist in those days, I could’ve used subroutines to mitigate the problem.) After a disastrous outcome, I quickly learned the value of solving complex problems by weaving together simple pieces.

When I started to write code for a living, I didn’t think to ask clients for written requirements and acceptance criteria. I did months of wasted work assuming that I understood their stated, though undocumented, business needs. I found out that despite good intentions, misunderstandings can occur when objectives aren’t specified and expectations aren’t recorded.