Tent Reef, Saba
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 24 Jan 2015 10:45 EST
Tue 13 Jan 2015 09:42 EST
I've often been involved in discussions about deliberately increasing the diversity of a group of people. The most common case in software is increasing the proportion of women. Two examples are in hiring and conference speaker rosters where we discuss trying to get the proportion of women to some level that's higher than usual. A common argument against pushing for greater diversity is that it will lower standards, raising the spectre of a diverse but mediocre group.
Mon 05 Jan 2015 11:26 EST
At goto Aarhus this year, there was a theme on internet privacy. Tim Bray gave a keynote on the state of browsers which touched on this issue and later gave a full conference talk on the state of internet privacy and security. Erik Dörnenburg and I gave a keynote explaining why we feel it is the responsibility of developers to defeat mass surveillance. Our colleague Ola Bini, who is very active in the internet security world himself, felt this was a good opportunity to get all of us together to discuss these issues in an interview.
Mon 05 Jan 2015 09:43 EST
There are various ways in which refactoring can fit into our programming workflow. One useful notion is that of Preparatory Refactoring. This is where I'm adding a new feature, and I see that the existing code is not structured in such a way that makes adding the feature easy. So first I refactor the code into the structure that makes it easy to add the feature, or as Kent Beck pithily put it "make the change easy, then make the easy change".
It always helps to use examples to explain things, and so I took the opportunity when I ran into a case while adding a new feature to my publication toolchain.
Sat 20 Dec 2014 15:24 EST
Thu 18 Dec 2014 09:45 EST
A couple of weeks ago I did a joint talk with my colleague Molly Bartlett Dishman about the interaction of agile software development and application architecture. We talk how these two activities overlap, explaining that architecture is a vital part of a successful agile project. We then move on to passing on tips for how to ensure that the architecture work is happening.
This talk was part of ThoughtWorks’s “Rethink” event in Dallas. There are also excellent talks by Brandon Byars on how enterprises should be restructured to take advantage of agile thinking and by “Pragmatic” Dave Thomas on the dangers of “agile” being co-opted by the big-methodology crowd that it was designed to oppose. (The latter is worth it just to enjoy Dave in a suit and tie.)
Molly and I will be reprising and updating our talk for the O’Reilly Architecture conference in March next year.
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.