4 ms·

> This is a good piece. ... That person you are trying to get to read the agile manifesto isn't not reading it because they are lazy, stupid or arrogant. They'v

> This is a good piece. ... That person you are trying to get to read the agile manifesto isn't not reading it because they are lazy, stupid or arrogant. They've been around the block and know they don't need it. Being "around the block" is no excuse for not keeping up to date in your profession. True, software development has faster hype cycles than other professions such as medical or legal professions. However, just as experienced doctors need to keep up to date with standards of care, software developers also need to keep up with best practices. The larger takeaway from this piece is that you don't need to read full books to understand latest developments. A developer that knows 10 programming languages does not need to read a 500 page book to learn their 11th language. But they should read one or two articles, and try a tutorial to get what they need from it. Software development is a profession, and like every profession it's subject to constant change. Keeping your head down and ignoring new developments is simply malpractice.

flohofwoe 7y ago
> Being "around the block" is no excuse for not keeping up to date in your profession. I think the key phrase in the parents comment is "agile manifesto". If you've "been around the block" you can detect bullshit earlier, and know what new developments are worth looking at and which to ignore right from the start. And to be honest, software development is full of irrational bullshit, both in big organizations, as well as "hipster startups". That's not a new thing, it's always been like that, most of the bullshit dies very quickly, but some sticks around for decades and does massive damage. One of the most important skills of a senior dev is a well developed bullshit detector (while not becoming a cynic).
- speedplane 7y ago
  > I think the key phrase in the parents comment is "agile manifesto". ... One of the most important skills of a senior dev is a well developed bullshit detector It seems that your gripe is mostly targeting "agile" and the related jargon. I remember clearly when the agile hype started and I was pretty disgusted by it ... just a bunch middle managers getting expensive certifications and inserting "process" that was getting in the way of productivity. But I've come around. Developers have always been "agile" (although they didn't call it that), it's just that engineering management was not. Before, managers liked to create giant specs dictating everything and flow charts with unrealistic timelines. "Agile" really changed that. Now the more modern trend is small iterative improvements, and more direct contact between developers and customers. If you view the agile hype as directed to engineers, it fails. But if you see it as enlightening engineering management, it far more palatable. Sure, engineers see "agile" as new words to describe the same thing they were already doing, but for many managers, it was something pretty new. Agile encouraged managers to get out of the way, and to allow developers to operate in the way they were most comfortable. Maybe agile is over-hyped, but it's still a big and impressive development. But even if you don't buy that, guess what, every engineer has an engineering manager managing them. If your manager is learning a bunch of new lingo and processes, it definitely behooves you to learn what they're learning before they do, to get in front of it. My point is only to keep learning and staying abreast of industry developments. Even if they seem like BS to you, they may not to the people around you.
  - watwut 7y ago
    Manifesto itself is mostly bullshit. Also agile did not made managers go out of way. They have daily standups, sprints, tiny 4 hours long max tasks to track and and generally more day to day control and more ability to poison every single day instead of just some days. There are plenty of good or irrelevant managers that poison nothing. But those who do are not minimize by agile at all.
yabadabadoes 7y ago
> True, software development has faster hype cycles than other professions such as medical or legal professions. Medical and legal are not having hype cycles that need to be kept up with in this way. They each have processes to test if a change is positive and then implement the change. For legal it is initially jurisdictional and not going with the change in the jurisdiction it happened is malpractice, yet not knowing the basics of New Orleans law in New York is normal. > Keeping your head down and ignoring new developments is simply malpractice. My general doctor knows nothing that is happening in the field of foot surgery (unless he injured his own foot.) Many of the complaints I see about people not keeping up is about people who are well aware of more alternatives and more details in the alternatives than the person complaining. I was quite shocked at the seeming ignorance when my company selected new window environments or revision control a number of years back. But they all knew more about more than one via previous choices the company had used in the decades before than I knew about subversion and git or gnome and kde. Many of the details I assumed would be relevant to transitioning were never particularly relevant to them. Any of them learning too much about the choice not chosen was pretty irrelevant and could become negative if it developed into pointless complaining once the consensus occurred.
- speedplane 7y ago
  > Medical and legal are not having hype cycles that need to be kept up with in this way. Medical and legal professions both have strong centralized authority. In the medical field, it's the professional organizations, in legal it's the judges, for architects there are safety and standards organizations. Software development doesn't have any such central authority, and the entire profession is also heavily influenced by biased business interests. So there's definitely a lot more BS and hype that floats around in software development. That said, just because it's harder to keep up and filter the real from the BS in software development, doesn't give you a pass to ignore it.
  - oh_sigh 7y ago
    Sure it does. Anyone can write a blog post about why you should do X, and then they write another blog post 5 years later about "Boy was I an idiot for suggesting X, do Y instead!"
moksly 7y ago
> Being "around the block" is no excuse for not keeping up to date in your profession. I work in the public sector where we both develop and buy software, and because of this I get to sit at both ends of the negotiation table. Agile dies the moment contract negotiations begin, because no one is actually going to give you money to start building a house and see how much you finish before you run out. Maybe agile actually works somewhere in academia, a start up or deep inside giant tech, but it sure isn’t how most of us buy software. We setup requirements, detailed project plans, risk analysis and all those other things the agile manifesto tells you not to. Sure we’ll call it agile, but it’s agile in name only and by then we would probably have been better off if no one ever read the damn thing.
- speedplane 7y ago
  > I work in the public sector where we both develop and buy software ... Agile dies the moment contract negotiations begin There's a pretty famous public sector counter example: the initial ObamaCare website. The initial site was contracted out using traditional waterfall development methodology and was a complete disaster. The rebuild was done with a far smaller team, at a far lower budget using agile methodologies. Things move pretty slowly in government, and I entirely understand that the existing government processes with big lump sum payments and rigorous accountability are not very conducive to agile development. However, it's not impossible (as with ObamaCare, it has been done before). The next time you have control over these negotiations, maybe push a bit harder for a more agile approach and see if it works.
  - BeetleB 7y ago
    >There's a pretty famous public sector counter example: the initial ObamaCare website. It's not a counterexample. Just because this method failed doesn't mean agile would have been better. And GP wasn't saying that the alternative to agile is better. He was saying that in such environments, the key stakeholders do not agree with agile (regardless of what they claim). Their demands and actions demonstrate this. People will not provide money for funding without guarantees that agile says not to provide.
  - brandonb 7y ago

flohofwoe 7y ago

> Being "around the block" is no excuse for not keeping up to date in your profession. I think the key phrase in the parents comment is "agile manifesto". If you've "been around the block" you can detect bullshit earlier, and know what new developments are worth looking at and which to ignore right from the start. And to be honest, software development is full of irrational bullshit, both in big organizations, as well as "hipster startups". That's not a new thing, it's always been like that, most of the bullshit dies very quickly, but some sticks around for decades and does massive damage. One of the most important skills of a senior dev is a well developed bullshit detector (while not becoming a cynic).

speedplane 7y ago
> I think the key phrase in the parents comment is "agile manifesto". ... One of the most important skills of a senior dev is a well developed bullshit detector It seems that your gripe is mostly targeting "agile" and the related jargon. I remember clearly when the agile hype started and I was pretty disgusted by it ... just a bunch middle managers getting expensive certifications and inserting "process" that was getting in the way of productivity. But I've come around. Developers have always been "agile" (although they didn't call it that), it's just that engineering management was not. Before, managers liked to create giant specs dictating everything and flow charts with unrealistic timelines. "Agile" really changed that. Now the more modern trend is small iterative improvements, and more direct contact between developers and customers. If you view the agile hype as directed to engineers, it fails. But if you see it as enlightening engineering management, it far more palatable. Sure, engineers see "agile" as new words to describe the same thing they were already doing, but for many managers, it was something pretty new. Agile encouraged managers to get out of the way, and to allow developers to operate in the way they were most comfortable. Maybe agile is over-hyped, but it's still a big and impressive development. But even if you don't buy that, guess what, every engineer has an engineering manager managing them. If your manager is learning a bunch of new lingo and processes, it definitely behooves you to learn what they're learning before they do, to get in front of it. My point is only to keep learning and staying abreast of industry developments. Even if they seem like BS to you, they may not to the people around you.
- watwut 7y ago
  Manifesto itself is mostly bullshit. Also agile did not made managers go out of way. They have daily standups, sprints, tiny 4 hours long max tasks to track and and generally more day to day control and more ability to poison every single day instead of just some days. There are plenty of good or irrelevant managers that poison nothing. But those who do are not minimize by agile at all.

yabadabadoes 7y ago

> True, software development has faster hype cycles than other professions such as medical or legal professions. Medical and legal are not having hype cycles that need to be kept up with in this way. They each have processes to test if a change is positive and then implement the change. For legal it is initially jurisdictional and not going with the change in the jurisdiction it happened is malpractice, yet not knowing the basics of New Orleans law in New York is normal. > Keeping your head down and ignoring new developments is simply malpractice. My general doctor knows nothing that is happening in the field of foot surgery (unless he injured his own foot.) Many of the complaints I see about people not keeping up is about people who are well aware of more alternatives and more details in the alternatives than the person complaining. I was quite shocked at the seeming ignorance when my company selected new window environments or revision control a number of years back. But they all knew more about more than one via previous choices the company had used in the decades before than I knew about subversion and git or gnome and kde. Many of the details I assumed would be relevant to transitioning were never particularly relevant to them. Any of them learning too much about the choice not chosen was pretty irrelevant and could become negative if it developed into pointless complaining once the consensus occurred.

speedplane 7y ago
> Medical and legal are not having hype cycles that need to be kept up with in this way. Medical and legal professions both have strong centralized authority. In the medical field, it's the professional organizations, in legal it's the judges, for architects there are safety and standards organizations. Software development doesn't have any such central authority, and the entire profession is also heavily influenced by biased business interests. So there's definitely a lot more BS and hype that floats around in software development. That said, just because it's harder to keep up and filter the real from the BS in software development, doesn't give you a pass to ignore it.
- oh_sigh 7y ago
  Sure it does. Anyone can write a blog post about why you should do X, and then they write another blog post 5 years later about "Boy was I an idiot for suggesting X, do Y instead!"

moksly 7y ago

> Being "around the block" is no excuse for not keeping up to date in your profession. I work in the public sector where we both develop and buy software, and because of this I get to sit at both ends of the negotiation table. Agile dies the moment contract negotiations begin, because no one is actually going to give you money to start building a house and see how much you finish before you run out. Maybe agile actually works somewhere in academia, a start up or deep inside giant tech, but it sure isn’t how most of us buy software. We setup requirements, detailed project plans, risk analysis and all those other things the agile manifesto tells you not to. Sure we’ll call it agile, but it’s agile in name only and by then we would probably have been better off if no one ever read the damn thing.

speedplane 7y ago
> I work in the public sector where we both develop and buy software ... Agile dies the moment contract negotiations begin There's a pretty famous public sector counter example: the initial ObamaCare website. The initial site was contracted out using traditional waterfall development methodology and was a complete disaster. The rebuild was done with a far smaller team, at a far lower budget using agile methodologies. Things move pretty slowly in government, and I entirely understand that the existing government processes with big lump sum payments and rigorous accountability are not very conducive to agile development. However, it's not impossible (as with ObamaCare, it has been done before). The next time you have control over these negotiations, maybe push a bit harder for a more agile approach and see if it works.
- BeetleB 7y ago
  >There's a pretty famous public sector counter example: the initial ObamaCare website. It's not a counterexample. Just because this method failed doesn't mean agile would have been better. And GP wasn't saying that the alternative to agile is better. He was saying that in such environments, the key stakeholders do not agree with agile (regardless of what they claim). Their demands and actions demonstrate this. People will not provide money for funding without guarantees that agile says not to provide.
- brandonb 7y ago