3 ms·

I feel like "agile processes" is an oxymoron. Real, actual agility requires a lot of thinking; something usually prevented by having processes in the first plac

I feel like "agile processes" is an oxymoron. Real, actual agility requires a lot of thinking; something usually prevented by having processes in the first place. A better question to ask an "Agile" team would be: "what problems are you trying to solve?" - most of the time they haven't taken the time to properly analyze the problem in the first place, even when the project is near completion. They just run with dumb user-stories and start piling up Jira tasks with no clear vision. At this point I don't believe Agile can work whatsoever. A success rate of one in a thousand projects, which usually happens to be a dead-simple CRUD app anyways, means absolutely nothing, other than it has failed in a spectacular way. If software development was an actual science instead of a pop culture, the scientific method would've thrown Agile out the window decades ago. Your last two sentences almost exclusively applies to web services, which is a tiny fraction of what software engineering can do. For me real agility is how much effort you're willing to spend upfront to properly analyze problems before attacking them, how quickly do you adapt your solution when new facts become known. Its dead-easy to have agility at the beginning of a project, what matters is still having it 2 years down the road and more. Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility.

flukus 10y ago
The last two sentences don't only apply to web based projects, they can apply to any application development from web to desktop to mobile. I think that would cover the vast majority of software developers. > Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility. The help in the sense that you can make and deploy changes seamlessly. For understanding code the unit tests that go along with them also help tremendously, if they are well written unit tests anyway.
- jeremiep 10y ago
  Oh yeah, but you could be spending 10 times the required amount of efforts because of accidental complexity and none of these tool will point that out for you. I've seen it happen way too often to trust a team relying heavily on processes and tools anymore. Besides, you set them up once and then forget about them, happy with your day to day use. But actually fighting complexity and making sure you're still solving the problem at hand and not bloating things up requires near constant critical thinking, something no tools or processes will ever be a replacement for. That's what I meant :)
wpietri 10y ago
> Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase I pretty strongly disagree with this. Simplicity in agile projects is achieve through continuous improvement of the code. All of those things make refactoring cheaper and easier, which means you can keep your code base in good shape as domain and business needs change. Without those supporting practices, people get scared to change anything. And once they get scared, bit rot sets in.
- jeremiep 10y ago
  > 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.

flukus 10y ago

The last two sentences don't only apply to web based projects, they can apply to any application development from web to desktop to mobile. I think that would cover the vast majority of software developers. > Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility. The help in the sense that you can make and deploy changes seamlessly. For understanding code the unit tests that go along with them also help tremendously, if they are well written unit tests anyway.

jeremiep 10y ago
Oh yeah, but you could be spending 10 times the required amount of efforts because of accidental complexity and none of these tool will point that out for you. I've seen it happen way too often to trust a team relying heavily on processes and tools anymore. Besides, you set them up once and then forget about them, happy with your day to day use. But actually fighting complexity and making sure you're still solving the problem at hand and not bloating things up requires near constant critical thinking, something no tools or processes will ever be a replacement for. That's what I meant :)

wpietri 10y ago

> Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase I pretty strongly disagree with this. Simplicity in agile projects is achieve through continuous improvement of the code. All of those things make refactoring cheaper and easier, which means you can keep your code base in good shape as domain and business needs change. Without those supporting practices, people get scared to change anything. And once they get scared, bit rot sets in.

jeremiep 10y ago
> 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.