I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. This site contains lots of my writing on software development, which primarily focuses on software design and agile methods. To find your way around this site, go to the intro guide.
My atom feed (RSS) announces any updates to this site, as well as various news about my activities and other things I think you may be interested in. I also make regular announcements via my twitter feed, which I copy to my facebook page.
Sat 30 Aug 2014 16:00 EDT
Thu 28 Aug 2014 10:11 EDT
As I talk to people about using a microservices architectural style I hear a lot of optimism. Developers enjoy working with smaller units and have expectations of better modularity than with monoliths. But as with any architectural decision there are trade-offs. In particular with microservices there are serious consequences for operations, who now have to handle an ecosystem of small services rather than a single, well-defined monolith. Consequently if you don't have certain baseline competencies, you shouldn't consider using the microservice style.
Wed 27 Aug 2014 08:35 EDT
Retread of post orginally made on 12 Aug 2004
When you a write a class, you mostly strive to ensure that the features of that class make sense for that class. But there are occasions when it makes sense to add a feature to allow a class to conform to a richer interface that it naturally should.
Tue 26 Aug 2014 09:22 EDT
A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance. In many circles maturity models have gained a bad reputation, but although they can easily be misused, in proper hands they can be helpful.
Sat 23 Aug 2014 15:28 EDT
Wed 13 Aug 2014 09:52 EDT
When I wrote Patterns of Enterprise Application Architecture, I coined what I called the First Law of Distributed Object Design: “don’t distribute your objects”. In recent months there’s been a lot of interest in microservices, which has led a few people to ask whether microservices are in contravention to this law, and if so why I am in favor of them?
Sat 09 Aug 2014 09:29 EDT
Wed 06 Aug 2014 09:34 EDT
Retread of post orginally made on 05 Aug 2004
My main inspiration in life is trying to capture and improve the way in which we do software development. So I spend a lot of time talking to people about various techniques they've used, which ones work well and which ones suck.
As I do this, I often hear about faulty techniques: "FIT wasn't worth the effort", "never put any logic in stored procedures", "test driven design led to a chaotic mess". The problem with any report of a faulty technique is to figure out if the technique itself is faulty, or whether the application of the technique was faulty.
Mon 04 Aug 2014 11:16 EDT
Retread of post orginally made on 02 Aug 2004
For as long as I've been in software there's been a debate between FunctionalStaffOrganization and TechnicalStaffOrganization. The debate occurs within project teams, and across whole IT organizations. It's a constant debate because both sides have good logical arguments to support them, and there's no real way to test which has an advantage in practice.
For a long time I’ve been a champion of Continuous Integration which reduces integration risk by integrating early and often, an application of the principle of Frequency Reduces Difficulty. We’ve found CI to be a core technique at ThoughtWorks and use it almost all the time. At the heart of this is a style of development that minimizes long feature branches with techniques like Branch By Abstraction and Feature Toggles.
While this is useful, there was still risk present from software that works in the development environment to getting it to work in production. As a result we developed Deployment Pipelines to reduce this risk, moving closer to our aim of Continuous Delivery: building software in such a way that we confidently deploy the latest builds into production whenever there is a business need. We find this improves feedback, reduces risk, and increases the visibility of project progress.
For more information: take a look at my guide page on Continuous Delivery.
I’ve been involved in enterprise software for two decades and while we’ve seen huge technological change during that time, the relational database has been a constant figure. Previous attempts to dethrone relational databases have failed, but some people think the new rise of NoSQL databases will finally consign relational databases to history. While I think relational databases are going to an important part of the landscape for a long time, I do think that there is a big change coming in the database field.
I discovered ThoughtWorks in 2000: then a small American company whose philosphy of software development was remarkably similar to my own. Now we’ve grown to around 2500 people world-wide, but kept the values that make us special. My colleagues have built critical systems for many clients in that time, and I’ve learned many lessons from them. While doing this, we found we often didn’t have the tools we needed, so we started to build them. This led to open-source tools such as CruiseControl, Selenium, Frank, and Moco as well as commercial products.
I have many opportunities, but I’ve stayed at ThoughtWorks because of the quality of my colleagues, who include both well-known speakers and those who may not be famous names but do an excellent job of software delivery (and feed me the information to write about). We are inspired by working with each other and our unusual three-pillar philosophy that raises professional excellence and social justice to the same level as financial performance.
And we are always looking for more great people to join our curious company. Maybe I’ll see you in one of our offices some day.
As with any style of process, agile software development has bred lots of interest in metrics. The thinking goes something like this, “We need a number to measure how we’re doing. Numbers focus people and help us measure success.” Whilst well intentioned, management by numbers unintuitively leads to problematic behavior and ultimately detracts from broader project and organizational goals. Metrics inherently aren’t a bad thing; just often, inappropriately used. Pat Kua, author of The Retrospective Handbook, demonstrates these issues and offers an alternative approach that uses metrics well.