7 ms·

> [Obligatory plug and disclaimer: Agile professional You sell process for a living. You claim, "After all, it's not like you can have no process at all. Wha

> [Obligatory plug and disclaimer: Agile professional You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right. Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming. Programming. Either learn and do it, or get the fuck out of its way.

brazzy 15y ago
Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...
- CodeMage 15y ago
  Funny thing is, both this guy and the author of the TFA touch the same problem in passing: regardless of the process, there are too many incompetent people plaguing our industry. Instead of addressing the problem, managers usually exacerbate it by trying to "fix it" with a "correct process". No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality. [1] http://en.wikipedia.org/wiki/Infinite_monkeys http://en.wikipedia.org/wiki/Infinite_monkeys
  - zbuc 15y ago
    Yet it never occurs to them when dividing people into groups that maybe they're the incompetent ones... Who's more competent? The person using Agile successfully and getting things done, the guy using no specific development process and getting things done, or the guy writing long blog posts about why he doesn't care for a development process he doesn't understand and doesn't need to participate in if he doesn't enjoy it?
    - babebridou 15y ago
      I'm currently on two missions. In one of these, we kick ass. Deliver on schedule or even in advance. It's scrum, we simply work as a team of four and ship, ship, ship, ship, feature after feature and fix after fix. We have our hands free, management is trusting our cell with the strategic future of their Tech tree, and we deliver. In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen. So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?
      - zbuc 15y ago
        The first you. The second you needs to run far away from what he's doing. :) I was in that situation before -- bad agile is BAD. I was on a team of 4 developers with literally 8 project managers. I know how that daily 1 hour crappy stand up goes. I also know how it feels to have deliverables for half the project managers in any given week, and what it's like to get constantly interrupted by 8 different people during your minimal development time to answer non-urgent questions. But you know what? Not everywhere is like that and you usually have a choice to find something else. You're obviously competent enough to find something else; you already have two things going on. If they aren't doing it right and they aren't listening and you aren't happy, GTFO.
- itsnotme 15y ago
  I enjoy programming with other programmers. But I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming. Cowboy is a complement. It doesn't mean "lone ranger" or "asshole", it means lazy, hard worker who takes the shortest path to greatest output. So, yup. Cowboy here.
  - vannevar 15y ago
    I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming. Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?
    - itsreallynotme 15y ago
      HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme. I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
      - vannevar 15y ago
        No but communication is part of any effective process. Standup is just having everyone say what they accomplished yesterday and what they're planning on doing today. If you're on a team with more than three or four people, it's a useful way to get a quick summary of where everyone's at. Some people are good at letting other people know when they're stuck, but some aren't, and if you've got the latter on your team standup is a good catchall. Most teams, whether they're in software, sales, or sports, have some variation of the standup. Of all the scrum paractices it seems like it should be the least controversial.
        itsreallynotme 15y ago
        No amount of process can fix bad communication. Standups are an attempt at that. Teams that have good communication succeed more, and standups aren't integral to their success. Teams with bad communication fail more, and standups can't help them. Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site. Tom: "Yesterday I.." Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?" Good teams communicate while they build, and know where each other are.
- jbooth 15y ago
  I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy. Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.
  - brazzy 15y ago
    It's ridiculously easy to get stuff done without any process when you work on your own and the projects are small enough for that. You don't even need to be very good to succeed in such a scenario. Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones. But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.
    - jbooth 15y ago
      Yeah man, I get that. I said that I'm at a small-a agile shop and it's working well for us. That doesn't change the fact that the only time I've seen the phrase 'cowboy programmer' used, it's as a preemptively ad hominem argument that anything besides Capital A Agile As Written On Stone Tablets can't possibly work. And if it does, it's cause they're cowboys. As a counterpoint, demanding something is deployed every 2 weeks, whether it's a 1-week task or a 3-week task, leads to plenty of cowboyism right within the process.
matwood 15y ago
Interesting. So how do you build things that take thousands of programming hours to complete? What about projects involving complex rulesets requiring legal input and/or HR input? Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.
- itsnotme 15y ago
  If you're planning a project to take thousands of programming hours to complete, you are an idiot, and nothing can help you.
  - disbelief 15y ago
    So, there's nothing worth building that can't be accomplished in under 1000 hours?
    - itsnotme 15y ago
      Lots of meaningful things take thousands of programmer hours. Projects where those thousands of hours are meticulously planned for by non-programmers (whether by using "Agile" or any other process that sits on top of the process of programming) are fucking doomed from the jump.
      - gnaffle 15y ago
        The software that keeps all modern airliners in the sky is written by companies that have lots and lots of process. Do you think those software projects are doomed from the jump just because there's a lot of process involved?
        stcredzero 15y ago
        The cost/benefit tradeoff is very different for those companies. Usually, no one almost dies when your social app goes belly-up.

brazzy 15y ago

Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...

CodeMage 15y ago
Funny thing is, both this guy and the author of the TFA touch the same problem in passing: regardless of the process, there are too many incompetent people plaguing our industry. Instead of addressing the problem, managers usually exacerbate it by trying to "fix it" with a "correct process". No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality. [1] http://en.wikipedia.org/wiki/Infinite_monkeys http://en.wikipedia.org/wiki/Infinite_monkeys
- zbuc 15y ago
  Yet it never occurs to them when dividing people into groups that maybe they're the incompetent ones... Who's more competent? The person using Agile successfully and getting things done, the guy using no specific development process and getting things done, or the guy writing long blog posts about why he doesn't care for a development process he doesn't understand and doesn't need to participate in if he doesn't enjoy it?
  - babebridou 15y ago
    I'm currently on two missions. In one of these, we kick ass. Deliver on schedule or even in advance. It's scrum, we simply work as a team of four and ship, ship, ship, ship, feature after feature and fix after fix. We have our hands free, management is trusting our cell with the strategic future of their Tech tree, and we deliver. In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen. So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?
    - zbuc 15y ago
      The first you. The second you needs to run far away from what he's doing. :) I was in that situation before -- bad agile is BAD. I was on a team of 4 developers with literally 8 project managers. I know how that daily 1 hour crappy stand up goes. I also know how it feels to have deliverables for half the project managers in any given week, and what it's like to get constantly interrupted by 8 different people during your minimal development time to answer non-urgent questions. But you know what? Not everywhere is like that and you usually have a choice to find something else. You're obviously competent enough to find something else; you already have two things going on. If they aren't doing it right and they aren't listening and you aren't happy, GTFO.
itsnotme 15y ago
I enjoy programming with other programmers. But I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming. Cowboy is a complement. It doesn't mean "lone ranger" or "asshole", it means lazy, hard worker who takes the shortest path to greatest output. So, yup. Cowboy here.
- vannevar 15y ago
  I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming. Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?
  - itsreallynotme 15y ago
    HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme. I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
    - vannevar 15y ago
      No but communication is part of any effective process. Standup is just having everyone say what they accomplished yesterday and what they're planning on doing today. If you're on a team with more than three or four people, it's a useful way to get a quick summary of where everyone's at. Some people are good at letting other people know when they're stuck, but some aren't, and if you've got the latter on your team standup is a good catchall. Most teams, whether they're in software, sales, or sports, have some variation of the standup. Of all the scrum paractices it seems like it should be the least controversial.
      - itsreallynotme 15y ago
        No amount of process can fix bad communication. Standups are an attempt at that. Teams that have good communication succeed more, and standups aren't integral to their success. Teams with bad communication fail more, and standups can't help them. Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site. Tom: "Yesterday I.." Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?" Good teams communicate while they build, and know where each other are.
jbooth 15y ago
I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy. Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.
- brazzy 15y ago
  It's ridiculously easy to get stuff done without any process when you work on your own and the projects are small enough for that. You don't even need to be very good to succeed in such a scenario. Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones. But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.
  - jbooth 15y ago
    Yeah man, I get that. I said that I'm at a small-a agile shop and it's working well for us. That doesn't change the fact that the only time I've seen the phrase 'cowboy programmer' used, it's as a preemptively ad hominem argument that anything besides Capital A Agile As Written On Stone Tablets can't possibly work. And if it does, it's cause they're cowboys. As a counterpoint, demanding something is deployed every 2 weeks, whether it's a 1-week task or a 3-week task, leads to plenty of cowboyism right within the process.

matwood 15y ago

Interesting. So how do you build things that take thousands of programming hours to complete? What about projects involving complex rulesets requiring legal input and/or HR input? Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.

itsnotme 15y ago
If you're planning a project to take thousands of programming hours to complete, you are an idiot, and nothing can help you.
- disbelief 15y ago
  So, there's nothing worth building that can't be accomplished in under 1000 hours?
  - itsnotme 15y ago
    Lots of meaningful things take thousands of programmer hours. Projects where those thousands of hours are meticulously planned for by non-programmers (whether by using "Agile" or any other process that sits on top of the process of programming) are fucking doomed from the jump.
    - gnaffle 15y ago
      The software that keeps all modern airliners in the sky is written by companies that have lots and lots of process. Do you think those software projects are doomed from the jump just because there's a lot of process involved?
      - stcredzero 15y ago
        The cost/benefit tradeoff is very different for those companies. Usually, no one almost dies when your social app goes belly-up.