The basic assumptions behind move fast and break things: * We don’t know what the final solution will look like, because of things like scope creep and client

The basic assumptions behind move fast and break things: * We don’t know what the final solution will look like, because of things like scope creep and client demands. * The more agile the team is, the higher the velocity and ability to iterate. * The more specialized roles we have (like project manager, team lead and junior developer) the more we can focus on completing tickets to increase velocity. Which I counter with: * We actually do know what the final solution will look like. I normally have an idea of what clients are asking for before they finish their sentences. Then I extrapolate to the fundamental problems and meta concepts around their specific problem. I’ve already formulated solutions and am solving them in my mind, until I isolate the unknown steps (the hard steps), whose odds of me being able to solve them are the basis of my estimate. Most of my work today goes into research, setup, glue code, infrastructure and maintenance. Solving the client’s actual problem constitutes perhaps 5% of the work I must do. * We can always iterate faster in our minds than in the real world. With a proper architecture budget, we can take time in the beginning to brainstorm the complete solution before we ever start writing code. Then if we follow proper quality assurance practices like test-driven development, we can write code that is free of technical debt and bugs. All the while exerting substantially less effort than writing the same thing several times. * Agile programming wasn’t really a thing until the rise of large internet companies and the marginalization of individual software developers. It’s curious to me that the people with the most say in writing solutions have the least clout in organizations. I feel that this is due to supply-side economics and wealth inequality. So today we cater to client first, then organization, then software developer. That’s what the specialization in agile is really all about. But we should be doing something more like movie production, so the client is the producer, the organization is the director (or movie studio) and developers are the actors. The industry should have more confidence in the process and have conventions which mitigate the churn caused by clients’ fickleness and low understanding of the problem domain. But right now it feels like the emphasis is on getting every scene filmed as fast as possible. We pretend that developers have no gravitas and are just interchangeable cogs in the machine. It’s no surprise to me that most productions bomb in the box office. To use construction as an analogy: programmers used to be akin to architects, spending time in the beginning to draft a plan that includes all contingencies so that the building doesn’t fall down (a right-brained or politically-blue approach based on creativity, insight, seeing outside the box, etc). Today we’re being told to be framers, hammering out solutions as fast as we can over and over again in order to get things done until the building is finished (a left-brained or politically-red approach based on a strong work ethic, discipline, loyalty, not getting distracted, etc). I think these are both important, and over the last year I have been working on my “getting things done” side to improve my execution ability. But I will always be a dreamer and value the intuitive side of software development. The idea that we can manifest solutions in the real world with the power of our minds is what got me into programming in the first place. The trend towards application and turning programming into just another job has soured me on the field in general. I’m actually not entirely certain that I can do it anymore. So to me, the true cost of move fast and break things is the loss of people like me who thought that this was all going to go a different direction.