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.
Fri 03 May 2013 13:36 BST
If you’re interested in techniques for estimation, you should take a look at this pdf ebook. It contains half-a-dozen essays on estimating in agile projects, drawn from our experiences with a wide range of clients. We explain approaches based on story points and on story counting, which should give you a good overview for you to explore an approach that will work for you.
Wed 01 May 2013 12:13 BST
The Dependency Inversion Principle (DIP) was coined by (Uncle) Bob Martin several years ago. It’s a useful principle to help organize the dependencies in your system. Here Brett Schuchert shows how this principle works in practice to simplify designs with a couple of real world examples from his recent ThoughtWorks projects.
Wed 24 Apr 2013 15:34 BST
User-journey tests are a form of BusinessFacingTest, designed to simulate a typical user's "journey" through the system. Such a test will typically cover a user's entire interaction the system in order to achieve some goal. They act as one path in a use case.
Wed 24 Apr 2013 15:34 BST
Story tests are BusinessFacingTests used to describe and verify the software delivered as part of a UserStory. When a story is elaborated the team creates several story tests that act as acceptance criteria for the story. The story tests can be combined into a regression suite for the software and provide traceability from the requirements (user stories) to tests and (through execution) to the behavior of the system. Story tests are usually BroadStackTests.
Wed 24 Apr 2013 15:32 BST
A business-facing test is a test that's intended to be used as an aid to communicating with the non-programming members of a development team such as customers, users, business analysts and the like. When automated, they describe the system in domain-oriented terms, ignoring the component architecture of the system itself. Business-facing tests are often used as acceptance criteria, having such tests pass indicates the system provides the functionality that the customer expects.
Tue 23 Apr 2013 16:24 BST
I’m hoping to spend more time writing about expositional architectures, systems that show interesting characteristics that will act as seeds for ideas for other software systems. To make a start I’ve written an infodeck describing the SCMS-PO system of Gap Inc. It’s a system for managing purchase orders with a rich javascript client talking to a java server system using a resource API. Interesting features include using knockout.js form of the Presentation Model pattern, a javascript validator running on both client and server, encapsulating data access with repositories, using MongoDB as an application database, and the testing portfolio.
Mon 22 Apr 2013 15:42 BST
User Stories are chunks of desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes. You also hear the same concept referred to as a feature, but the term "story" or "user story" has become prevalent in agile circles these days.
Mon 22 Apr 2013 15:41 BST
A component test is a test that limits the scope of the exercised software to a portion of the system under test. It is in contrast to a BroadStackTest that's intended to exercise as much of the system as is reasonable.
Mon 22 Apr 2013 15:40 BST
A broad-stack test is a test that exercises most of the parts of a large application. It's often referred to as an end-to-end test or full-stack test. It lies in contrast to a ComponentTest, which only exercises a well-defined part of a system.
Mon 22 Apr 2013 15:39 BST
In Javascript, promises are objects which represent the pending result of an asynchronous operation. You can use these to schedule further activity after the asynchronous operation has completed by supplying a callback.
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 a quick introduction into what is happening, take a look at our infodeck on why we think the future is not so much NoSQL but more that of Polyglot Persistence. For more depth take a look at our new book: NoSQL Distilled. On this site you can find more material by looking at the nosql guide.
Over the last couple of years, we’ve seen mobile development become an increasing part of our work at ThoughtWorks. A habitual question is how to deal with the many kinds of mobile devices that are out there. Recently I published an infodeck on developing software for multiple mobile devices. This explores the dangers of a naive cross-platform approach, explores the trade-offs between multiple native apps versus a web app, and looks into hybrid approaches.
In a complementary article Giles Alexander writes about how to allocate effort across different platforms . He outlines two opening gambits - laser focuses on doing a single platform really well while cover-your-bases maximizes the number of platforms to aim at. He talks about the choice between these openings and how to build on them. Giles is also the maintainer of Calatrava - an open-source framework to assist building hybrid mobile applications.
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 1500 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 and Selenium, and to products. We have Mingle for project collaboration and mangement, Go for Continuous Delivery, and Twist for automated functional testing.
Despite the Great Recession, the last couple of years have been our most successful - and we are always looking for more people to join us.
For a long time I’ve been a champion of Continuous Integration which reduces the integration risk by integrating early and often. We’ve found CI to be a core technique at ThoughtWorks and use it almost all the time. 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 techniques to reduce this risk, moving closer to our aim of 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.
