It’s not how I’d write software. Hundreds of developers on one code base. Lots of proposal writing and design work before embarking on code. PR-based code review meaning it can take days - or longer - for a change to hit the main branch. Minimal pairing, no stand-ups. Long release cycles meaning the first real customer feedback on a change might be months after it (finally) lands in main.
It’s not how I’d write software.
And yet, and yet. It’s exactly how I do write software. And it’s an extremely successful way of writing software. Look at Kubernetes. Look at Knative. Look at any number of big multi-company open source projects built this way.
It’s not how I’d write software. And yet it’s how I do write software. And yet it’s a great way, if you want to build a project with (much) more than a two pizza team, if you want to build a big community of contributors, if you want to create a common platform that lots of companies can trust and use and build together, to build software. In fact, if you want those things, it might be the only realistic way to write software.
The paradox of big distributed open source. Almost everything I think I know - thought I knew, confidently - about how to write software: small teams, pairing, 100% TDD, stand-ups, a single prioritised backlog, an on-site customer, fast feedback loops, iteration, continuous delivery, is not how we build software in big distributed open source. And is not, I’m increasingly convinced, how we should build software in big distributed open source, at least where big contributor communities and shared multi-employer participation are a requirement.
I don’t have a conclusion. I’m still learning, I’m thinking out loud. I find the way the changing context invalidates some of my previously held assumptions about building software exciting and surprising - perhaps I shouldn’t: that’s what changing contexts are supposed to do.
It’s not how I’d write software.
And yet, and yet. It’s exactly how I do write software. And it’s an extremely successful way of writing software. Look at Kubernetes. Look at Knative. Look at any number of big multi-company open source projects built this way.
It’s not how I’d write software. And yet it’s how I do write software. And yet it’s a great way, if you want to build a project with (much) more than a two pizza team, if you want to build a big community of contributors, if you want to create a common platform that lots of companies can trust and use and build together, to build software. In fact, if you want those things, it might be the only realistic way to write software.
The paradox of big distributed open source. Almost everything I think I know - thought I knew, confidently - about how to write software: small teams, pairing, 100% TDD, stand-ups, a single prioritised backlog, an on-site customer, fast feedback loops, iteration, continuous delivery, is not how we build software in big distributed open source. And is not, I’m increasingly convinced, how we should build software in big distributed open source, at least where big contributor communities and shared multi-employer participation are a requirement.
I don’t have a conclusion. I’m still learning, I’m thinking out loud. I find the way the changing context invalidates some of my previously held assumptions about building software exciting and surprising - perhaps I shouldn’t: that’s what changing contexts are supposed to do.