Feels like the old php metric. PHP had a ton of great code and successful projects but it also attracted very bad devs as well as very inexperienced devs leading to a real quality problem.
Honestly kinda see thing in a lot of JavaScript applications these days. Brilliant code but also a ton of bad code to the point I get nervous opening a new project.
My point? It may be a tough pill but it’s not the project framework that makes projects fail, it’s how the project is run.
I witnessed a huge number of failed projects in my 25-year career. The cause was almost always the same: inexperienced developers trying to create a reusable product that could be applied to imagined future scenarios, leading to a vastly overcomplicated mess that couldn’t even satisfy the needs of the original client. Made no difference what the language or framework was or what development methodology was utilized.
I’ve seen a lot of contractors over promising timelines too. “No matter how hard you push and no matter what the priority, you can’t increase the speed of light.”
I feel like that’s the same underlying issue: The requirements are not understood upfront.
If a customer cannot give you any specific information, you cannot cut any corners. You’re pretty much forced to build a general framework, so that as the requirements become clearer, you’re still equipped to handle them.
I guess, the alternative is building a prototype, which you’re allowed to throw away afterwards. I’ve never been able to do that, because our management does not understand that concept.
I feel like that’s the same underlying issue: The requirements are not understood upfront.
Actually on most of these failed projects the requirements of the original customer were pretty clear. But the developers tried to go far beyond those original requirements. It is fair to say that the future requirements were not well understood.
the alternative is building a prototype, which you’re allowed to throw away afterwards
Lol I’ve done many prototypes. The problem is that management sees them and says “oh, so we’re finished with the project already? Yay!”
“agile” is being flexible. Being “Agile” more often than not means your company’s incompetent management paid some hack consultants to come in and bless your flavor of stupid bureaucracy as “Agile”.
Yeah, look at the most prolific language at a given time. There’s your crappy projects or your soon-to-be-crappy projects. What are the universities and ‘coding academies teaching’? That’s going to be the crappiest stuff in the world when those students come out.
So too it goes with ‘management’, the popular ‘self-help’ style crap of the moment is what crappy teams will adopt, and no matter what methodology it is, that crap team is still crap, and it will reflect on that methodology.
Feels like the old php metric. PHP had a ton of great code and successful projects but it also attracted very bad devs as well as very inexperienced devs leading to a real quality problem.
Honestly kinda see thing in a lot of JavaScript applications these days. Brilliant code but also a ton of bad code to the point I get nervous opening a new project.
My point? It may be a tough pill but it’s not the project framework that makes projects fail, it’s how the project is run.
I witnessed a huge number of failed projects in my 25-year career. The cause was almost always the same: inexperienced developers trying to create a reusable product that could be applied to imagined future scenarios, leading to a vastly overcomplicated mess that couldn’t even satisfy the needs of the original client. Made no difference what the language or framework was or what development methodology was utilized.
I’ve seen a lot of contractors over promising timelines too. “No matter how hard you push and no matter what the priority, you can’t increase the speed of light.”
But yeah exactly.
Preach brother!
I feel like that’s the same underlying issue: The requirements are not understood upfront.
If a customer cannot give you any specific information, you cannot cut any corners. You’re pretty much forced to build a general framework, so that as the requirements become clearer, you’re still equipped to handle them.
I guess, the alternative is building a prototype, which you’re allowed to throw away afterwards. I’ve never been able to do that, because our management does not understand that concept.
Actually on most of these failed projects the requirements of the original customer were pretty clear. But the developers tried to go far beyond those original requirements. It is fair to say that the future requirements were not well understood.
Lol I’ve done many prototypes. The problem is that management sees them and says “oh, so we’re finished with the project already? Yay!”
Agile falls into the category of how the project is run
No it’s a set of tools you can use to run a project.
My point is that a lot of people use “agile” to mean not planning or don’t put guard rails on scope and they fail. That’s not agile, it’s just bad PM
Agreed.
Being Agile is being flexible. To do that you need to plan for multiple contingencies. Resulting in more planning, not none.
“agile” is being flexible. Being “Agile” more often than not means your company’s incompetent management paid some hack consultants to come in and bless your flavor of stupid bureaucracy as “Agile”.
Yeah, look at the most prolific language at a given time. There’s your crappy projects or your soon-to-be-crappy projects. What are the universities and ‘coding academies teaching’? That’s going to be the crappiest stuff in the world when those students come out.
So too it goes with ‘management’, the popular ‘self-help’ style crap of the moment is what crappy teams will adopt, and no matter what methodology it is, that crap team is still crap, and it will reflect on that methodology.