Systems and Thinking

Prologue This blog is designed to be the first of a multi-part series. If I find the motivation it will become a book. My interest with computers really kicked off when I discovered Linux, the ability to inspect and understand what was going on, including reading the source code, enabled me to gain a much richer understanding of what my computer was doing and why things weren't working how I wanted them to. I have had a pretty unusual career path for a Software Developer, I started as a support engineer for proprietary monitoring software for which I didn’t get to see the source code let alone write it. Then I became a System Administrator, debugging a lot of networking, storage, database, operating systems and more proprietary software. I, like many others, am not satisfied if I fix a problem and don't understand how. My brain has trouble letting go of that feeling. The satisfaction of understanding a bug that has stumped me and others for a long time is almost as addictive as...

  5 or so years ago a manager at my company, Leon Messerschmidt , gave a talk to our engineering department called “Why I don’t use the term Technical Debt and you shouldn’t either” and since then I’ve wanted to write my own view on this. Before then I had felt uncomfortable with the term, it seemed very subjective. In the talk Leon described how the term debt was often viewed as a good thing by people with a financial background (as he had) and so gave the wrong impression to non-engineering stakeholders. What Leon advocated for was instead a “Tidy as you go” approach, which reflects a lot of what Kent Beck went on to describe in his series of blog posts and book : If you only have a minute to read, here are the classic software design blunders: Thou shalt not rewrite the whole system. Thou shalt not pause delivery of features for an extended period to fix the design. Thou shalt not delay the first feature to "get the design right". Thou shalt not thoughtlessly demand the...