> Emphasize that the most important part of software development is moving fast.
This doesn't seem to me to be true. Can you expand on your thoughts here?
I'd agree that the ability to move fast is an essential part of effective software development, but I don't think it's the most important (the most important is producing business value accurately and reliably), and I think that moving fast for the sake of moving fast is likely to result in moving quickly in the wrong direction. In particular, it's easy to be so worried about moving fast that you have no time to take new business needs/opportunities into account (see also Tom DeMarco's Slack), and it's easy to get excited about shiny new technology and spend a lot of time implementing it and roleplaying Google for no reason, which is a great way to move very quickly while not delivering a cent of business value.
Finding somewhere with formal process, with full-time managers who aren't reluctantly moved to management for career advancement, with clear hierarchy and goals, was an important part of my most recent job search, simply because, as a good engineer, I hate to see my work go to waste. I have heard the same sentiment from lots of my talented friends.
Unless you take conscious steps to remain flexible and to eliminate barriers to productivity, you're going to find your ability to "produc[e] business value" diminished because effort will get sucked into process instead, and for reasons nobody can identify. Soon enough, you'll find yourself wondering why you have so many developers, all of whom appear to be doing work, yet without getting anything done.
By default, all software development organizations slow down. I say that developer velocity is the most important goal because, without focusing on this velocity, you end up solidifying, like a cooling lava, and it becomes difficult to accomplish any of your other goals.
Well, okay, you and I are agreeing that velocity is nice to have, but why is it the most important goal?
I can make the exact same argument about automated regression tests. As the size of your codebase grows and the number of customers (i.e., people triggering edge cases) grows, unless you take conscious steps to make sure that every build doesn't regress previous bugs, all your effort will get sucked into diagnosing and fixing things that you've fixed before. And all your developers will be fixing bugs but you won't be fixing new bugs and certainly not shipping features.
In particular, if you want to refactor / rewrite parts of your code to improve development velocity, you'll suffer from the well-documented problem (see e.g. https://www.joelonsoftware.com/2000/04/06/things-you-should-... ) of losing all the knowledge of the weird edge cases you've fixed along the way. So, testing is strictly more important than development velocity!
I can make the same argument about a half-dozen other development best practices, and I'll have actual citations to back them up. Why is development speed the most important goal, why is formal process the enemy of speed (instead of its friend, because it makes sure work doesn't get duplicated or wasted!), and what is your evidence for these claims?
In particular, if your claim is true, we would not expect to see as much feature development / new products from old, large companies (I'm thinking of Oracle, Microsoft, Apple, Amazon, etc.) as we do. We would expect to see these companies grind to a halt and perform poorly in the markets (investors really want to see growth, not just continuing to be as good as you were last year), and that's not what's happening.
Your focus on "process" is missing the deeper truth: companies don't slow down because some busybody managers put in processes, it's because as organizations (and codebases) grow, they become more complex and more difficult to change.
It's not a question of preventing formal processes, doing that indiscriminately is a recipe for disaster; every engineer will do things their own way, and once the head count exceeds the ability for everyone to talk to each other daily, there will be an explosion in complexity and duplicated effort. Rather, you need to put in the right processes, maintain them just as you would code, and kill them when they no longer serve the company. Where "process" goes wrong is when it's used as a hammer to address issues that would be better served by team structure, common tooling or architecture. For instance, if you have a quality issue, adding more code reviews will generally cost a lot more, and do a worse job than making the responsible team wear the pager for their own code.
The real secret sauce to staying agile as a company grows is small, cross-functional teams. This is where SOA (microservices for the kiddies) really pays for its overhead—by decoupling human teams and giving them agency. This won't make a big company as agile as a startup, because that's literally impossible, but Amazon and Facebook have shown how much more agile it can make you than any prior megacorp.
> This is where SOA (microservices for the kiddies) really pays for its overhead—by decoupling human teams and giving them agency.
Funny you mention microservices, because I've been thinking about Susan Fowler's book about them and how the advice is basically "Here's how we made sure that we kept up our agility by introducing tons of process before anyone could think of deploying a microservice, because otherwise every team would do literally everything their own way and it would be great until it turned into an unquenchable tirefire."
I'm not aware of Uber's technology organization having stopped producing business value. That company has a lot of problems, but the inability of their software engineers to engineer software doesn't seem to be one of them.
This doesn't seem to me to be true. Can you expand on your thoughts here?
I'd agree that the ability to move fast is an essential part of effective software development, but I don't think it's the most important (the most important is producing business value accurately and reliably), and I think that moving fast for the sake of moving fast is likely to result in moving quickly in the wrong direction. In particular, it's easy to be so worried about moving fast that you have no time to take new business needs/opportunities into account (see also Tom DeMarco's Slack), and it's easy to get excited about shiny new technology and spend a lot of time implementing it and roleplaying Google for no reason, which is a great way to move very quickly while not delivering a cent of business value.
Finding somewhere with formal process, with full-time managers who aren't reluctantly moved to management for career advancement, with clear hierarchy and goals, was an important part of my most recent job search, simply because, as a good engineer, I hate to see my work go to waste. I have heard the same sentiment from lots of my talented friends.