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.
News and Updates
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.
Thu 23 Jun 2016 09:37 EDT
I hated carrots when I was growing up, hating the smell and texture of the things. But after I left home and started to cook for myself I started to like them. Nothing changed about the carrots, nor did my taste buds get a radical overhaul, the difference was in the cooking. My mother, like so many English people of her generation, wasn't a great cook - particularly of vegetables. Her approach was to boil carrots for twenty minutes or more. I since learned that if you cook them properly, carrots are a totally different experience.
This isn't a site about cooking, but about software development. But I find that often a technique or tool is like the poor carrot - blamed for being awful when the real problem is that the technique is being done incorrectly.
Tue 21 Jun 2016 10:07 EDT
Bimodal IT is the flawed notion that software systems should be divided into these two distinct categories for management and control.
- Front Office systems should be optimized for rapid feature development. These systems of engagement need to react rapidly to changing customer needs and business opportunities. Defects should be tolerated as the necessary cost for this rapid development cycle.
- Back Office systems should be optimized for reliability. As systems of record, it's important that you don't get defects that damage the enterprise. Consequently you slow down the rate of change.
Mon 20 Jun 2016 11:08 EDT
Sun 19 Jun 2016 09:25 EDT
Fri 17 Jun 2016 08:29 EDT
Serverless architectures often get tangled with PaaS or are thought of as a #NoOps approach that gets rid of operational demands. Mike's article now looks at those comparisons.
Thu 16 Jun 2016 15:35 EDT
Thu 16 Jun 2016 11:47 EDT
Mike introduced the notion of Function as a Service (FaaS) in the first part of his serverless article. In this installment he expands on this, unpacking Amazon's description of their Lambda product to develop a general definition of FaaS. This includes important characteristics around state, execution duration, startup latency, and the role of API Gateways.
Wed 15 Jun 2016 09:22 EDT
One of the latest architectural styles to appear on the internet is that of Serverless Architectures, which allow teams to get rid of the traditional server engine that sits behind their web and mobile applications. Mike Roberts has been working with teams that have using this approach and has started writing an evolving article to explain this style and how to use it. He begins with describing what "serverless" means - with a couple of examples of how more usual designs become serverless.
Sat 11 Jun 2016 10:09 EDT
Wed 08 Jun 2016 09:30 EDT
A business-capability centric team is one whose work is aligned long-term to a certain area of the business. The team lives as long as the said business-capability is relevant to the business. This is in contrast to project teams that only last as long as it takes to deliver project scope.
Wed 01 Jun 2016 09:31 EDT
People who sponsor development of software usually aren’t very interested in development metrics such as velocity or frequency of deployment to production. They care more about business benefits that the software will deliver such as lower manual effort, better sales conversion, greater customer satisfaction, i.e business outcomes. Outcome-oriented teams are those that are mandated and equipped to deliver business outcomes, such teams have people with the capability to carry out all necessary activities to realize the outcome.. By contrast, ActivityOriented teams are neither equipped nor mandated to do so. They can only perform one of several activities required to realize an outcome.
Wed 01 Jun 2016 09:31 EDT
Any significant software development effort requires several different activities to occur: analysis, user experience design, development, testing, etc. Activity-oriented teams organize around these activities, so that you have dedicated teams for user-experience design, development, testing etc. Activity-orientation promises many benefits, but software development is usually better done with OutcomeOriented teams.
Sat 28 May 2016 12:46 EDT
Wed 25 May 2016 09:08 EDT
If you need to store your users' passwords, it's essential that you never store them plainly. Instead you must store a cryptographic hash of them, so that people who get access to your database don't get the passwords. Cade and Daniel explain how to do this properly: salting the hash to avoid lookup table attacks, and using an appropriate hashing algorithm to defend against well-equipped attackers.
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 be 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 4000 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.