4 ms·

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers. It's n

by api 15y ago

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers. It's not, and it can't be made so. Programming is a highly skilled craft. Good code is written by good programmers. Bad code is written by bad programmers. Bad management can hobble good programmers, but no form of management can make bad programmers write good code. (I'm not saying agile is bad, necessarily, just that it does not live up to its hype.)

BadassFractal 15y ago
I feel you got it backwards. The whole idea behind agile is to treat programming as a craft and to focus on the people, as opposed to treating development as a production line. Some good readings on the subject: Extreme Programming Explained, Agile Software Development Ecosystems, Balancing Agility and Discipline.
- oconnore 15y ago
  My problem with this is the 4th tenet: "Responding to change over following a plan". Some tasks require lots of planning. When you are building a complex system, you cannot plan as you go, and in some cases your first usable release cannot happen after the first 'sprint'. In this way, agile programming assumes that the programmer cannot make long term development plans, and in fact prevents him from doing so. While this eliminates some of the risk, it also prevents programmers from reasoning about their problem holistically, and can deliver inferior or non functioning solutions for projects that do not happen to fit the model well. This refusal to allow programmers to reason holistically is part of what us critics mean when we say that agile attempts to turn programmers into line workers. Complex projects, like building a jetliner (or the programming equivalent), cannot be "continuously integrated" with no up front planning. For projects like this, you need to decide the thrust of your engines before you start to design the airframe, or your entire project may fall apart, literally.
  - BadassFractal 15y ago
    It really depends on the kind of project you're working on. Some modern Agile authorities (see Balancing Agility and Discipline: A Guide for the Perplexed) will tell you that you should tailor the process to your specific requirements. They would never recommend that you use XP for the development of life-critical software that has hundreds of engineers working on it. Agile is born from rapid prototyping and makes a lot of sense for that environment. If you're doing work where one day you might be developing one thing, and the next day you might be working on a completely different product altogether, then reducing the cost of change is the only thing that makes sense. If you're not, then don't use pure agile, it doesn't make that much sense. There's obviously an issue with one size fits all approaches to agile, and as agile matures people realize that more and more, instead of forcing you to do everything by the book. The point is, as you get more and more experience with driving software projects, you need to be smart enough to understand what will make sense and what won't.
    - wpietri 15y ago
      I agree with your general direction, but I have a quibble. Agile methods were born from in-house enterprise software projects. The ur-project for Extreme Programming was a payroll system, and SCRUM's was something similarly dull. The original SCRUM paper says, "Scrum is concerned with the management, enhancement and maintenance of an existing product[...]. Scrum is not concerned with new or re-engineered systems development efforts." If I'm doing rapid prototyping, that's when I'm least interested in Agile techniques like pair programming, test-driven development, and refactoring. Those only really pay off in the long haul.
  - wpietri 15y ago
    No serious agilist suggests that you never plan, or that all projects can deliver a useful release in a week. Indeed, Agile teams see planning as something so important that you do it frequently. What they're opposed to is blindly following an old plan in the face of new circumstances. If you are lucky enough to work in a domain where you can reliably plan years or decades ahead, then you can still happily use Agile methods. Incremental delivery still lets you get more for your money by putting the most valuable parts of the system in production first. But if, like most people, you have competitors, or if you learn new things when you put your product in the hands of users, then the ability to respond to change is absolutely vital. In that case, holistic reasoning is an ongoing process, not something that happened once, years ago.
- api 15y ago
  Every capital-A Agile deployment I've ever seen uses Scrum to try to run programmers like line cooks.
MartinCron 15y ago
Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers It's sad that so many people have that perspective. I've always looked at it in the opposite way. I mean, the first part of the agile manifesto is "People over Process" and the first wave of agile evangelists were actual programmers and not fad-prone management types.
- philwelch 15y ago
  Yes, but actual programmers with an altruistic desire to improve the state of software development are never going to be as loud and noisy as various salesmen (agile consultancies, agile coaches, agile tool developers) and hence the latter group of people are going to take over the word "agile".
  - MartinCron 15y ago
    I totally agree, and it makes me sad. Just because some snake-oil salesmen are selling it, doesn't mean it's snake-oil, it just means that opportunists smell an opportunity. The altruists who are trying to improve the state of the art are still out there, if you know where to look.
gbhn 15y ago
Agreed. I think agile, while incorporating some good ideas (testing makes better code! talking with the customers helps you figure out what they want!), ends up in practice looking like a shyster scheme and burning a lot of businesses and programmers.

by api 15y ago

BadassFractal 15y ago

I feel you got it backwards. The whole idea behind agile is to treat programming as a craft and to focus on the people, as opposed to treating development as a production line. Some good readings on the subject: Extreme Programming Explained, Agile Software Development Ecosystems, Balancing Agility and Discipline.

oconnore 15y ago
My problem with this is the 4th tenet: "Responding to change over following a plan". Some tasks require lots of planning. When you are building a complex system, you cannot plan as you go, and in some cases your first usable release cannot happen after the first 'sprint'. In this way, agile programming assumes that the programmer cannot make long term development plans, and in fact prevents him from doing so. While this eliminates some of the risk, it also prevents programmers from reasoning about their problem holistically, and can deliver inferior or non functioning solutions for projects that do not happen to fit the model well. This refusal to allow programmers to reason holistically is part of what us critics mean when we say that agile attempts to turn programmers into line workers. Complex projects, like building a jetliner (or the programming equivalent), cannot be "continuously integrated" with no up front planning. For projects like this, you need to decide the thrust of your engines before you start to design the airframe, or your entire project may fall apart, literally.
- BadassFractal 15y ago
  It really depends on the kind of project you're working on. Some modern Agile authorities (see Balancing Agility and Discipline: A Guide for the Perplexed) will tell you that you should tailor the process to your specific requirements. They would never recommend that you use XP for the development of life-critical software that has hundreds of engineers working on it. Agile is born from rapid prototyping and makes a lot of sense for that environment. If you're doing work where one day you might be developing one thing, and the next day you might be working on a completely different product altogether, then reducing the cost of change is the only thing that makes sense. If you're not, then don't use pure agile, it doesn't make that much sense. There's obviously an issue with one size fits all approaches to agile, and as agile matures people realize that more and more, instead of forcing you to do everything by the book. The point is, as you get more and more experience with driving software projects, you need to be smart enough to understand what will make sense and what won't.
  - wpietri 15y ago
    I agree with your general direction, but I have a quibble. Agile methods were born from in-house enterprise software projects. The ur-project for Extreme Programming was a payroll system, and SCRUM's was something similarly dull. The original SCRUM paper says, "Scrum is concerned with the management, enhancement and maintenance of an existing product[...]. Scrum is not concerned with new or re-engineered systems development efforts." If I'm doing rapid prototyping, that's when I'm least interested in Agile techniques like pair programming, test-driven development, and refactoring. Those only really pay off in the long haul.
- wpietri 15y ago
  No serious agilist suggests that you never plan, or that all projects can deliver a useful release in a week. Indeed, Agile teams see planning as something so important that you do it frequently. What they're opposed to is blindly following an old plan in the face of new circumstances. If you are lucky enough to work in a domain where you can reliably plan years or decades ahead, then you can still happily use Agile methods. Incremental delivery still lets you get more for your money by putting the most valuable parts of the system in production first. But if, like most people, you have competitors, or if you learn new things when you put your product in the hands of users, then the ability to respond to change is absolutely vital. In that case, holistic reasoning is an ongoing process, not something that happened once, years ago.
api 15y ago
Every capital-A Agile deployment I've ever seen uses Scrum to try to run programmers like line cooks.

MartinCron 15y ago

Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line-workers It's sad that so many people have that perspective. I've always looked at it in the opposite way. I mean, the first part of the agile manifesto is "People over Process" and the first wave of agile evangelists were actual programmers and not fad-prone management types.

philwelch 15y ago
Yes, but actual programmers with an altruistic desire to improve the state of software development are never going to be as loud and noisy as various salesmen (agile consultancies, agile coaches, agile tool developers) and hence the latter group of people are going to take over the word "agile".
- MartinCron 15y ago
  I totally agree, and it makes me sad. Just because some snake-oil salesmen are selling it, doesn't mean it's snake-oil, it just means that opportunists smell an opportunity. The altruists who are trying to improve the state of the art are still out there, if you know where to look.

gbhn 15y ago

Agreed. I think agile, while incorporating some good ideas (testing makes better code! talking with the customers helps you figure out what they want!), ends up in practice looking like a shyster scheme and burning a lot of businesses and programmers.