Continuous Integration and Delivery
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’ve been collaborating with my colleague Pramod Sadalage, on exploring and explaining this shift. For more information take a look at the nosql guide.
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.
