“Build versus buy” decisions are everywhere today, and rightly so. Building software is risky and expensive, and software product companies can spread that risk and expense across multiple customers. But my colleague Brandon Byars argues that the kinds of tools that are available to buy for systems integration are not products that directly solve a business problem.
more… https://martinfowler.com/articles/cant-buy-integration.html
Within each normal-sized team, limit the choice of alternatives for any class of technology to three. These are: the current sensible default, the one we're experimenting with as a trial, and the one that we hate and want to retire. The conversation goes like this: We want to introduce a new messaging technology. How many do we have already in place? Oh we have three in active use, including one that's considered legacy and we're partway through migrating off and one that we experiment
Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Reco
Integrating the necessary security controls and audit capabilities to satisfy compliance requirements within a DevOps culture can capitalize on CI/CD pipeline automation, but presents unique challenges as an organization scales. Understanding the second order implications and unintended consequences caused by the chosen implementation is key to building an effective, secure, and scalable solution. My colleague Carl Nygard describes how to think of these cho
James Shore has revised his book "The Art of Agile Development". I'm pleased to write a foreword for this book as it is solid guide to learning how to get past faux-agile and develop the skills you need to get the benefits of the agile way of work.
more… https://martinfowler.com/articles/art-agile-foreword.html
Those of us developing software don’t need to be told what a big impact it’s had on humanity this century. I’ve long maintained that this places a serious responsibility on our profession. Whether asked to or not, we have a duty to ensure our systems don’t degrade our society. But in the tumult of so many software projects, it can be difficult to step back and understand the implications of our work. In the last few months my colleagues at Thoughtworks have been putting together a catalog of tec
I've written a fair bit about how using pull requests can encourage a low integration frequency, reducing cycle time and discouraging refactoring. Rouan Wilsenach has had success using an approach that categorizes changes as Ship/Show/Ask - using this classification to decide whether and how to use pull requests.
A couple of months ago I announced that I was stepping back from speaking. A few people wondered whether I would still be writing. I did indicate in that article that I am, but I felt it may be worth saying a bit more about what I’m concentrating on these days. more… https://martinfowler.com/articles/202107-what-doing-now.html
We often need to access APIs from foreign codebases, and these foreign codebases usually have different vocabularies to ours. I've found it useful to encapsulate this interaction with a gateway that translates between our code and foreign code.
more… https://martinfowler.com/articles/gateway-pattern.html