5 ms·

> Simplicity in agile projects is achieve through continuous improvement of the code. This is also called "emergent architecture" and its a big lie. You'll at

> Simplicity in agile projects is achieve through continuous improvement of the code. This is also called "emergent architecture" and its a big lie. You'll at best reach a fraction of the quality you'd have by thinking about said architecture upfront with twice the development time - it works for CRUD projects simply because such projects are dead-simple to begin with. How are these practices helping us reason about the simplicity of the codebase? How are the people dependent on your code going to handle all of your frequent refactors? What does continuous deployment even mean outside of the web? How do you refactor something as big as a game engine with 10+ projects built on top of it? More importantly, how are you going to add proper abstractions to an existing project? No refactoring tool will ever do that, it cant be automated and the more advanced a project becomes the harder they become to introduce in the codebase. I've seen plenty of "best practices" projects that were just huge hairy balls of indirections. Yet everyone on the team felt good about it because none knew any better. You can't judge practices based on how they work for one particular area of software development. Especially when said area is one of the simplest out there.

wpietri 10y ago
> You can't judge practices based on how they work for one particular area of software development. Especially when said area is one of the simplest out there. You know exactly nothing about what I've based my opinion on. Because all you've done is jump in and rant about your beliefs. > thinking about said architecture upfront with twice the development time Design quality is limited by the information you have, and no amount of thinking creates information. The beginning of the project is when you have the least information about everything: domain, users, user needs, business needs, technology, team. Everything. You mostly get information by trying things in the world. And actually trying things in the world is the only real test of ideas that come from thinking. If your methodology requires understanding everything up front, then it's basically useless in the real world. Even if you could perfectly understand your intended market and use case, that will change over time. But you can't, because your competitors are always plotting to beat you, and they will not share their plans with you. Amazon, for example, has been in operation 20 years, and could easily be going for decades more. If in the early days they had tried to write code capable of dealing with their current needs, let alone their needs from 2050, they would have been idiots. Pure up-front design is an unworkable fantasy. > More importantly, how are you going to add proper abstractions to an existing project? No refactoring tool will ever do that [...] Refactoring existed before automated tools, and mostly exists beyond it. Tools help, but it's mostly a human activity. Try reading Fowler's book on this, and his subsequent writing. You can't effectively criticize something you don't even understand.

wpietri 10y ago

> You can't judge practices based on how they work for one particular area of software development. Especially when said area is one of the simplest out there. You know exactly nothing about what I've based my opinion on. Because all you've done is jump in and rant about your beliefs. > thinking about said architecture upfront with twice the development time Design quality is limited by the information you have, and no amount of thinking creates information. The beginning of the project is when you have the least information about everything: domain, users, user needs, business needs, technology, team. Everything. You mostly get information by trying things in the world. And actually trying things in the world is the only real test of ideas that come from thinking. If your methodology requires understanding everything up front, then it's basically useless in the real world. Even if you could perfectly understand your intended market and use case, that will change over time. But you can't, because your competitors are always plotting to beat you, and they will not share their plans with you. Amazon, for example, has been in operation 20 years, and could easily be going for decades more. If in the early days they had tried to write code capable of dealing with their current needs, let alone their needs from 2050, they would have been idiots. Pure up-front design is an unworkable fantasy. > More importantly, how are you going to add proper abstractions to an existing project? No refactoring tool will ever do that [...] Refactoring existed before automated tools, and mostly exists beyond it. Tools help, but it's mostly a human activity. Try reading Fowler's book on this, and his subsequent writing. You can't effectively criticize something you don't even understand.