4 ms·

I'm _very_ disillusioned by blaming lots of software process as a bailout for bad devs. I dislike most software process (agile), but I think some of the process

I'm _very_ disillusioned by blaming lots of software process as a bailout for bad devs. I dislike most software process (agile), but I think some of the processes defined by agile are mostly just branded common sense. Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. Sometimes heavily scrutinized, reasonable process doesn't need to be modified. Sometimes the devs do.

the_other 6y ago
> Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. If you go to the original agile manifesto, it’s basically just this. It’s consciously against packaged, branded solutions. I’m fond of Scrum. The most coherent and comfortable jobs I’ve had used Scrum. Also one of the worst (in terms of productivity) tried it too. It seems to me that the overall system can be a problem, but it wont be the whole story. Sometimes the client/product/management sides of things lead to counter-productive work. Sometimes developers silo themselves, or think too much about their code and not enough about the product & users. Sometimes the product sucks. It seems to me the hardest bit is defining, scoping and agreeing the units of work, appropriate to the size of team and aims of the product. If you get this wrong, the product will suffer. It takes some input from everyone to get this part right, and you can make it work with any system, branded or not. It’s just hard. I’m not saying you need reps from all departments in all your meetings, I’m saying you need everyone to work within and around the framework in a way that gets the product made. EDIT: type.
mrkurt 6y ago
I think it's more frequently a bailout for bad management. Either because a manager sucks, or a team can't self manage.
- alexbanks 6y ago
  Maybe I'm taking "Bad management" to literally mean "Bad managers", when people mean "the process of management"? Is a team that cannot self manage not (for software teams) a dev problem?
  - mrkurt 6y ago
    I definitely mean "the process of management". A team that can't self manage is just a bad team. You can have a lot of great people on a bad team, so I don't think it's exactly a dev problem. It's a "whoever puts teams together" problem. There are lots of people who benefit from a named manager. Expecting people to self manage who don't really want to is as bad as micro managing people. I know because I f'd this up at least 3 times building my last company. ;)
    - alexbanks 6y ago
      Ahhhhh - yes, totally agree with you.
deckard1 6y ago
> Care about your work. Care about your project. I think this is the crux of many problems plaguing software development today. Unless you're at a brand-spanking-new startup or have been handed the keys to an exciting greenfield project, you're going to be on a legacy project. Which means a combination of adding new features to a pile of cruft, or fixing bugs in that pile of cruft. This is where it becomes problematic: no one stays at a company longer than a year or two. Industry compensation does not work in the favor of the person dedicating years to a single company and/or project. Which means there is a built in don't-give-a-shit factor to every software project today. Not that the rockstar coders of yesterday ever gave much of a crap of the quality of code they left in their wake, but industry incentives turn us all into code monkeys. And if you happen to be the guy or girl that cares and is staying at the company many years, you'll surely witness a parade of ladder climbers come and go and absolutely destroy the quality of your hard work and effort. I could go on about title inflation, and the fact that only about 1 in 5 devs is, in my book, truly a senior today. But we're way off topic now.

the_other 6y ago

> Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. If you go to the original agile manifesto, it’s basically just this. It’s consciously against packaged, branded solutions. I’m fond of Scrum. The most coherent and comfortable jobs I’ve had used Scrum. Also one of the worst (in terms of productivity) tried it too. It seems to me that the overall system can be a problem, but it wont be the whole story. Sometimes the client/product/management sides of things lead to counter-productive work. Sometimes developers silo themselves, or think too much about their code and not enough about the product & users. Sometimes the product sucks. It seems to me the hardest bit is defining, scoping and agreeing the units of work, appropriate to the size of team and aims of the product. If you get this wrong, the product will suffer. It takes some input from everyone to get this part right, and you can make it work with any system, branded or not. It’s just hard. I’m not saying you need reps from all departments in all your meetings, I’m saying you need everyone to work within and around the framework in a way that gets the product made. EDIT: type.

mrkurt 6y ago

I think it's more frequently a bailout for bad management. Either because a manager sucks, or a team can't self manage.

alexbanks 6y ago
Maybe I'm taking "Bad management" to literally mean "Bad managers", when people mean "the process of management"? Is a team that cannot self manage not (for software teams) a dev problem?
- mrkurt 6y ago
  I definitely mean "the process of management". A team that can't self manage is just a bad team. You can have a lot of great people on a bad team, so I don't think it's exactly a dev problem. It's a "whoever puts teams together" problem. There are lots of people who benefit from a named manager. Expecting people to self manage who don't really want to is as bad as micro managing people. I know because I f'd this up at least 3 times building my last company. ;)
  - alexbanks 6y ago
    Ahhhhh - yes, totally agree with you.

deckard1 6y ago

> Care about your work. Care about your project. I think this is the crux of many problems plaguing software development today. Unless you're at a brand-spanking-new startup or have been handed the keys to an exciting greenfield project, you're going to be on a legacy project. Which means a combination of adding new features to a pile of cruft, or fixing bugs in that pile of cruft. This is where it becomes problematic: no one stays at a company longer than a year or two. Industry compensation does not work in the favor of the person dedicating years to a single company and/or project. Which means there is a built in don't-give-a-shit factor to every software project today. Not that the rockstar coders of yesterday ever gave much of a crap of the quality of code they left in their wake, but industry incentives turn us all into code monkeys. And if you happen to be the guy or girl that cares and is staying at the company many years, you'll surely witness a parade of ladder climbers come and go and absolutely destroy the quality of your hard work and effort. I could go on about title inflation, and the fact that only about 1 in 5 devs is, in my book, truly a senior today. But we're way off topic now.