4 ms·

I asked an experienced Bridge player about bidding conventions, and if there was one right way to bid a hand. He said, "there isn't one right way to bid, but th

I asked an experienced Bridge player about bidding conventions, and if there was one right way to bid a hand. He said, "there isn't one right way to bid, but there are plenty of wrong ways." That's how I feel about software development (and business operations in general). Is there an inflexible, one-size-fit-all, "right" methodology? Hell no. Even open allocation (which isn't really a methodology) isn't right for every company out there. There are, however, a ton of wrong ways to do things. The sad thing is that, because most people are driven by a mix of ego and incompetence, wrong ways of doing things are the most common. You're Doing It Wrong if: * managers have more power than engineers. * mutually positive contributions (good for engineer and for firm) are disallowed for political reasons. * people can't get shit done because of too much pointless process (to start writing code, you need a Jira ticket). * stand-up takes 45 minutes and people sit down. * people are micromanaged and start doing things badly, or overmonitored (the hidden danger of too much Jira activity) and start panic-coding. * designs are made by incompetents. * ... and many, many more.

scott_w 14y ago
Interestingly, you did exactly what the author warned against, but replaced "right" with "wrong". Some things are obvious (designs made by incompetent designers), but then giving the example of "No code without a Jira ticket" is almost certainly your personal pet peeve.
- michaelochurch 14y ago
  My point is that "no code without a Jira ticket" is a bad process. Slapping reporting overhead on small code changes is ridiculous. Maybe I didn't make that clear. I don't support that. I have a lot of pet peeves, because I've seen so much done wrong. Competent software managers are extremely uncommon. Maybe 1 in 20. In the '90s, people who studied day traders found that they were reliably making money on their core strategies, but those were generally only available for a small amount of time, and that most of them lost their shirts through "boredom trading" outside of their core competence that had zero-to-negative expectancy and only added noise. Boredom trading occurs because ego, combined with a need to feel active, results in a lot of activity that cuts away at the profits earned during one's good hour or two per day. Managers are a case of trader boredom. They'd actually be quite effective if they scaled back to 1/10 the amount of process and interference, but their trader boredom just causes them to throw everything out of whack. If managers were socially permitted to work 5-10 hours per week instead of being expected to fill time by bothering people, they'd probably do a much better job.
  - prof_hobart 14y ago
    Why is it a bad process? I know little to nothing about Jira (although I have worked in environments in the past where you don't start work on a defect without taking some form of ticket, and it didn't seem fundamentally bad).
    - malyk 14y ago
      You find a typo on the website. Instead of pull, switch the "i" to an "o", commit, push which takes 30 seconds you have: 1.) Open web browser 2.) go to your JIRA url 3.) enter your username/password 4.) enter your password again because you mis-typed it 5.) find the project page for that particular project and wait for it to load 6.) find the place where you add new tickets and wait for that to load 7.) type in a bunch of bullshit on a long form and submit that 8.) Hopefully you get to assign the bug to yourself. God forbid you have to have a PM do the actual assignment! 9.) pull, make the change, push 10.) go back into jira and open the ticket 11.) write a description of how you fixed the "bug" 12.) close the ticket Ok, so that's the worst case, but the only real work you should /need/ to do is #9. The whole process of creating/assigning/closing the ticket probably only takes a minute or two, but it's probably unnecessary in most software systems and, over time, adds a ton of frustration where none is needed.
      - michaelochurch 14y ago
        Right. That's the kind of nonsense that managers are OK with because they think that it's more important to monitor performance on an hour-by-hour basis than let you get into flow and actually perform.
      - prof_hobart 14y ago
        I like the way that the stuff you think you need is rolled up into a single "pull, make the change, push" yet the stuff you don't see any value in is spread out into having to open the application, go to the site, get things wrong etc. If it's browser-based, could you not simply have a browser link to to "Add ticket" to replace most of the first 6 steps? Also, "type in a bunch of bullshit on a long form and submit that" - like I say, I don't know Jira, but I doubt that it forces you to type a long bit of bullshit. I'm sure that "correct spelling" would do. And I'd also expect that you'd be doing something similar in your source control system so that someone looking through the code at some point in the future can see why (or when) the particular change was made. And how often do you make this kind of change as opposed to actually working on bugs/improvements that are coming in through JIRA? I'm sure that there are occasions when your tool gets in the way of getting the work done, but from your description I'm not sure it sounds like it's a major inconvenience most of the time, which needs to be balanced against the benefit you get from having a centralised place to track, prioritise and allocate the work.
colanderman 14y ago
You just described my workplace. No wonder I'm frustrated working there.

scott_w 14y ago

Interestingly, you did exactly what the author warned against, but replaced "right" with "wrong". Some things are obvious (designs made by incompetent designers), but then giving the example of "No code without a Jira ticket" is almost certainly your personal pet peeve.

michaelochurch 14y ago
My point is that "no code without a Jira ticket" is a bad process. Slapping reporting overhead on small code changes is ridiculous. Maybe I didn't make that clear. I don't support that. I have a lot of pet peeves, because I've seen so much done wrong. Competent software managers are extremely uncommon. Maybe 1 in 20. In the '90s, people who studied day traders found that they were reliably making money on their core strategies, but those were generally only available for a small amount of time, and that most of them lost their shirts through "boredom trading" outside of their core competence that had zero-to-negative expectancy and only added noise. Boredom trading occurs because ego, combined with a need to feel active, results in a lot of activity that cuts away at the profits earned during one's good hour or two per day. Managers are a case of trader boredom. They'd actually be quite effective if they scaled back to 1/10 the amount of process and interference, but their trader boredom just causes them to throw everything out of whack. If managers were socially permitted to work 5-10 hours per week instead of being expected to fill time by bothering people, they'd probably do a much better job.
- prof_hobart 14y ago
  Why is it a bad process? I know little to nothing about Jira (although I have worked in environments in the past where you don't start work on a defect without taking some form of ticket, and it didn't seem fundamentally bad).
  - malyk 14y ago
    You find a typo on the website. Instead of pull, switch the "i" to an "o", commit, push which takes 30 seconds you have: 1.) Open web browser 2.) go to your JIRA url 3.) enter your username/password 4.) enter your password again because you mis-typed it 5.) find the project page for that particular project and wait for it to load 6.) find the place where you add new tickets and wait for that to load 7.) type in a bunch of bullshit on a long form and submit that 8.) Hopefully you get to assign the bug to yourself. God forbid you have to have a PM do the actual assignment! 9.) pull, make the change, push 10.) go back into jira and open the ticket 11.) write a description of how you fixed the "bug" 12.) close the ticket Ok, so that's the worst case, but the only real work you should /need/ to do is #9. The whole process of creating/assigning/closing the ticket probably only takes a minute or two, but it's probably unnecessary in most software systems and, over time, adds a ton of frustration where none is needed.
    - michaelochurch 14y ago
      Right. That's the kind of nonsense that managers are OK with because they think that it's more important to monitor performance on an hour-by-hour basis than let you get into flow and actually perform.
    - prof_hobart 14y ago
      I like the way that the stuff you think you need is rolled up into a single "pull, make the change, push" yet the stuff you don't see any value in is spread out into having to open the application, go to the site, get things wrong etc. If it's browser-based, could you not simply have a browser link to to "Add ticket" to replace most of the first 6 steps? Also, "type in a bunch of bullshit on a long form and submit that" - like I say, I don't know Jira, but I doubt that it forces you to type a long bit of bullshit. I'm sure that "correct spelling" would do. And I'd also expect that you'd be doing something similar in your source control system so that someone looking through the code at some point in the future can see why (or when) the particular change was made. And how often do you make this kind of change as opposed to actually working on bugs/improvements that are coming in through JIRA? I'm sure that there are occasions when your tool gets in the way of getting the work done, but from your description I'm not sure it sounds like it's a major inconvenience most of the time, which needs to be balanced against the benefit you get from having a centralised place to track, prioritise and allocate the work.

colanderman 14y ago

You just described my workplace. No wonder I'm frustrated working there.