About

Things at work keep getting worse. More and more, engineers are stripped of autonomy, transformed into replaceable factory workers with no more responsibility than the next (pre-approved, pre-prioritized, pre-architected) ticket they pull off the product backlog. I love computer programming but as a profession it is almost unbearable. Rethinking Software pushes back against this trend by exploring practices that restore autonomy, quality and professionalism to our craft.

My interest in this effort began in 2016, when I published a list of reasons that Scrum was the wrong way to build software. The response was fiercely divided. For half my readers I was speaking a long ignored truth, validating their frustrations. For the other half I was either ignorant or a liar — doing harm to the world of software engineering for speaking out. Two things were clear. First, a large group of developers in the industry were hurting and appreciated having someone at least try to speak to their pain. Second, the rest of the software industry, the ones that were interested in keeping the Scrum party going, were certainly not interested in being challenged and intended on continuing this march of doom indefinitely. I was left with a deep desire to re-establish developer happiness through empathy and positive change.

With time, I observed more dis-empowering practices than just Scrum. They were infesting the whole software development life-cycle. The label “best practice" became a tool to render them incontrovertible.

Because speaking up at work only labeled me an agitator, and realizing that the pro-scrum, pro-best-practices crowd were holding all the cards, writing became my only recourse — the only safe way to question authority. From this sprung Rethinking Software.

Rethinking Software is a place to explore ideas about software engineering, even if they are outside the industry mainstream. Because sometimes it takes a fresh look to make progress.