Who am I?

I’m Andy Butcher, an experienced software engineer who has worked in various industries, predominantly as a developer or architect, but I’ve worn many different hats including support, systems admin, training, management, and leadership. The role I keep coming back to, though, is solutions architect – it’s where I find I can add the greatest value because of the combination of my hands-on technical knowledge, communication skills, and understanding of the relationship between people systems, business, and software systems.
Like so many people in the industry, I found a passion for coding as a teenager, with a particular interest in artificial intelligence, which is what I went on to do at university. However, with the Internet taking off dramatically, my expertise became web technologies. That’s probably still my deepest area of knowledge, although over the years I’ve worked at literally all levels of the “stack” and on a wide variety of back end systems and infrastructure, including Cloud and Serverless.
Definition Of Done is the company I started when I began contracting, and for now it’s just me. That may change in the future, but this site is also where I blog about software development, architecture, and organisational design.
Why “Definition Of Done”?

I called my company Definition Of Done after the concept developed by Ken Schwaber and Jeff Sutherland in their Scrum framework for agile software development in the 1990s.
They define it as follows:
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
https://scrumguides.org/scrum-guide.html
Like many people, Scrum was one of the first agile development approaches I tried, along with eXtreme Programming (XP), and it rocked my world. Previously I’d only been exposed to much more dogmatic ways of doing things, and reading about Agile felt like a homecoming. It matched how I liked to work – breaking down problems, and constantly communicating and reassessing to reduce risk. Instead of spending several months before releasing any value or discovering major problems, we could learn and act fast.
These days, like most seasoned professionals in the industry, I now use elements of many different methodologies and frameworks like a toolbox – some formal, some less formal – choosing the right technique for the job at hand, depending on the type of project or product, and, crucially, the organisational context. I’m certified by TOGAF, BCS, and AWS, but I’m also qualified in Agile and Lean practices. I’ve ridden the waves of both ITIL and Site Reliability Engineering, and worked with everything from SOA to microservices, container orchestration to Serverless. I don’t believe in the one true answer, or silver bullets. Every context and problem requires different tools and solutions.
And Ken and Jeff’s “definition of done” is just one of those tools. I sometimes propose it to teams who are struggling with quality, or finding that their non-functionals or operational concerns are being neglected until the last second (or in some cases maybe altogether). I decided to call my company Definition Of Done because those things matter a lot. As Neal Ford said:
Architecture is abstract until it’s operationalized
https://nealford.com/memeagora/2015/03/30/architecture_is_abstract_until_operationalized.html
Software spends months being developed, but years running in Production. So we need to make sure it’s operationally ready before we launch it.

Done is an important concept. It means we defined what outcomes we needed, and we achieved them. It means we managed risk. It means we did our jobs well, and everyone involved can feel proud of what they did – which is an essential component of what it means to feel fulfilled in your work. And since motivated, fulfilled people make the best teams, it leads to great software, and great outcomes for organisations.
If you want to talk about how I could help your project, team, or organisation, just get in touch for a chat. Alternatively, have a read about how I work.

