Software Ideologies
-
Eric Lynch wrote:
Ranting wasn't as much fun as I hoped. I tried it. I don't think its the thing for me after all.
Your rant is too verbose, lacking insults, too intellectual, and not sufficiently emotive. ;) Here's a rewrite: > Software methodologies implies people have the intelligence to actually come up with logical methods. Instead management creates arbitrary rules in knee jerk reactions resulting in arbitrary software ideologies that we become mindless slaves to, genuflecting to the process god hoisted onto his throne, only to be cast into oblivion and replaced by a new god by the next manager and his particular psychosis. OK, still too intellectual, probably still too verbose. :-D
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
still too intellectual, probably still too verbose.
:elephant: software methodologies! Neither intellectual nor verbose. :) Can anyone beat my record of three words?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Yet another victim of the [broken window fallacy](https://www.investopedia.com/ask/answers/08/broken-window-fallacy.asp) :sigh:
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Thanks. I was unfamiliar with that one. I like the analogy.
-
Eric Lynch wrote:
Ranting wasn't as much fun as I hoped. I tried it. I don't think its the thing for me after all.
Your rant is too verbose, lacking insults, too intellectual, and not sufficiently emotive. ;) Here's a rewrite: > Software methodologies implies people have the intelligence to actually come up with logical methods. Instead management creates arbitrary rules in knee jerk reactions resulting in arbitrary software ideologies that we become mindless slaves to, genuflecting to the process god hoisted onto his throne, only to be cast into oblivion and replaced by a new god by the next manager and his particular psychosis. OK, still too intellectual, probably still too verbose. :-D
Latest Article - Building a Prototype Web-Based Diagramming Tool with SVG and Javascript Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Speaking as a master ranter! Don't get me wrong, I look forward to reading your rants.
Never underestimate the power of human stupidity RAH
-
In my experience the problem is mostly just programmers who can't write decent software. I've heard programmers say "software architecture isn't going to work for us, that's only nice in theory." So no UI, business and data layers, no abstractions, no nothing. No matter your software ideology, that's going to end bad (they were lucky that the software didn't change all that much). Then I've seen software with a gazillion useless layers, just as bad. Or software that took a non-DI library and used it as DI (the result was a very awkward method to instantiate objects when you need them, and no DI of course). A completely wrong implementation of an ORM and the programmers who made the mess cursing the ORM (the problem really wasn't the ORM)... Or a "core" library that every application depended on, but which changed almost daily. These are programmers of all ages, not just the old farts. No matter how clear or vague the business requirements are or how well your business structure is or how good the tools are you use, such software never ends well. Maybe we should just learn to write software properly first. After that we can worry about tools and methodologies.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Fir point although I don;t think our collective gripes are about software, per se, rather the gift wrapping it all seems to come with now mostly forced upon people by gullible managers. Still, each to their own.
Keep your friends close. Keep Kill your enemies closer. The End
-
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu. Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair. I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one. So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass. So, anyhow, here goes...ranting powers activate... I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge. They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah! Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off. OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad! I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant. "You can't do it that way." Why? Because, the methodology says its wrong. My favorite example is the Manifesto for Agile Software Development (http://agilemanifesto.org/). We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes. However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us. Step 1: Save the World - Some people with good intentions, recog
From my 20+years of IT/software work the methodologies used don't appear to have had a huge impact on the outcome. The one thing that has determined the success/failure of projects I have worked on has been the quality of communication between people in the team. Where there has been a culture of people not talking to each other or screaming and swearing/threatening each other the outcome has generally been fairly poor. Whereas when the has been a more friendly and supportive/mentoring culture the outcome of projects has generally always been one of success. So my experience tells me that it's not necessarily the methodology that counts but the quality of communication between people in a team/business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu. Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair. I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one. So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass. So, anyhow, here goes...ranting powers activate... I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge. They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah! Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off. OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad! I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant. "You can't do it that way." Why? Because, the methodology says its wrong. My favorite example is the Manifesto for Agile Software Development (http://agilemanifesto.org/). We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes. However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us. Step 1: Save the World - Some people with good intentions, recog
Reminds me of our discussion last friday. Branching merging strategy using git. First unroll 2 great undiscussible banners gotten from some conference displaying the one and only true strategy. Find it incomplete. Google it. Finding two other one and only true strategies. Discussion which one is the one and only true one. Finding both of them incomplete. Then I broke out: we should combine them in a way that works for us and declare that one the one and only true one. Being lynched for criticising the existing one and only true one strategies. Sitting back listening another hour. Discussion found no result, to be continued. AAAAAAAAAAHH. Leave me out please. Hey, you left over some ranting energy ^^
-
Sander Rossel wrote:
In my experience the problem is mostly just programmers who can't write decent software.
I have worked with some real jerks. One guy in particular found an old and odd definition of a csv file, different to Lotus and MSFT (and everyone else for that matter) and he insisted on using his version in his code. Result, it couldnt read a csv created by say excell. And he did it just because he could argue he was 'right'. Crazy eh? Yet his line leader and manager let him get away with it. They were scared of offending him. I have worked with other plain incompetent engineers who dont know why a UI locks up when its thread is asked to do heavy processing. That team actually threw away an app I wrote just to write their own, and because they couldnt understand function pointers, and made a complete mess of it. One of the main reasons is fear of the new, the unknown. It is surprising how many SW engineers once they know something, cling to it, desperately. How unadaptable they are to new ways of thinking, and how attached to their code they are, as if it is their flesh and blood. All of this makes for a very bad engineer.
That is interesting dichotomy i our software world. Some just run for shiny new frameworks, some dig trenches around their favourite tools. Maybe there are situations where someone sticks to some tools but in other he looks for new. Fun part is both taken to extreme make bad developers.
-
Reminds me of our discussion last friday. Branching merging strategy using git. First unroll 2 great undiscussible banners gotten from some conference displaying the one and only true strategy. Find it incomplete. Google it. Finding two other one and only true strategies. Discussion which one is the one and only true one. Finding both of them incomplete. Then I broke out: we should combine them in a way that works for us and declare that one the one and only true one. Being lynched for criticising the existing one and only true one strategies. Sitting back listening another hour. Discussion found no result, to be continued. AAAAAAAAAAHH. Leave me out please. Hey, you left over some ranting energy ^^
Been there and had those discussions. Once, I had a meeting to discuss the schedule and agenda for another meeting. Sometimes it amazes me that any actual work ever gets done :)
-
From my 20+years of IT/software work the methodologies used don't appear to have had a huge impact on the outcome. The one thing that has determined the success/failure of projects I have worked on has been the quality of communication between people in the team. Where there has been a culture of people not talking to each other or screaming and swearing/threatening each other the outcome has generally been fairly poor. Whereas when the has been a more friendly and supportive/mentoring culture the outcome of projects has generally always been one of success. So my experience tells me that it's not necessarily the methodology that counts but the quality of communication between people in a team/business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
I've been fortunate to have a couple of good technical managers over the decades...they're almost as much of a rarity as unicorns. Instead of enforcing policy, the better managers protected the team from politics, helped establish a direction when there were competing visions within the team, and just generally made sure we had the resources we needed to complete the work. Those were fun jobs and unsurprisingly those teams were very productive. So, my experience, you simply put together a few talented engineers with a supportive manager and great things happen. Hmmm...that seems like an easy formula...maybe I should jot down a few guidelines, add a few rules, and write a book...what could go wrong? :)
-
Munchies_Matt wrote:
Crazy eh? Yet his line leader and manager let him get away with it. They were scared of offending him.
I've worked with people like that. The problem was that the really bad programmer pretty much build the system single handed and he was the only one who really knew what was going on. He got mad and stressed when he saw something he didn't understand, like lambda's in any other setting than LINQ :sigh: And in the Netherlands it's quite difficult and/or expensive to fire anyone, so that's not really an option as long as he delivers something.
Munchies_Matt wrote:
It is surprising how many SW engineers once they know something, cling to it, desperately. How unadaptable they are to new ways of thinking, and how attached to their code they are, as if it is their flesh and blood.
They sound just like people ;) The scary part is that this type of behavior is pretty much the default human configuration. Doctors, lawyers, politicians... They all share those same traits :~
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Doctors, lawyers, politicians, plumbers, mechanics, BOSSES, etc.....When I was young I had this notion that people were generally competant, say, 99% of the time. Now that I have seen what there is to see, my estimate is less than 50% are competant and almost none should be completely trusted.
-
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu. Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair. I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one. So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass. So, anyhow, here goes...ranting powers activate... I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge. They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah! Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off. OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad! I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant. "You can't do it that way." Why? Because, the methodology says its wrong. My favorite example is the Manifesto for Agile Software Development (http://agilemanifesto.org/). We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes. However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us. Step 1: Save the World - Some people with good intentions, recog
There's definitely something of a cargo cult built around some methodologies. I recently worked with an ardent TDD disciple who would get a little upset with my view that TDD might have its place but that it wasn't the panacea for all things. I didn't get to see any of his work until after he left. Sure, all the unit tests were passed, but sadly, it wasn't quite the same story when it came to user tests. In fact, it couldn't have been more different. Everything was about as dysfunctional as it could possibly be. There's a dangerous belief at work there, namely: "I am doing this properly so I have no need to worry about anything going wrong." It's every bit as ill-founded as the idea that if we build the runway, the great iron bird will arrive laden with goodies, and its equally fallacious in that it comes with that implicit guarantee - "this is the way and the way cannot fail." Once we remove the possibility of failure from our expected outcomes (probably something that various new age barkers would actually advocate), we're left in a state where we stop thinking about how we'll deal with the inevitable. Rather than planning how we'll bubble up our exceptions, we just shrug our shoulders and say "Exceptions? What exceptions? There won't be any exceptions!" It's this complacency that tends to make rigid devotion to a methodology a very dangerous thing. The wise course is to cherry pick these things to suit our projects. A few core unit tests are obviously a good idea in many situations, so let's use them but the minute that we start to think that we've come across a fool-proof way to write bug-free software, we're off in the woods with the fairies and the unicorns and we haven't got a cat in hell's chance of coming back in one piece.
98.4% of statistics are made up on the spot.
-
Doctors, lawyers, politicians, plumbers, mechanics, BOSSES, etc.....When I was young I had this notion that people were generally competant, say, 99% of the time. Now that I have seen what there is to see, my estimate is less than 50% are competant and almost none should be completely trusted.
Some people would call that pessimism. I call that experience and wisdom :D
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
That is interesting dichotomy i our software world. Some just run for shiny new frameworks, some dig trenches around their favourite tools. Maybe there are situations where someone sticks to some tools but in other he looks for new. Fun part is both taken to extreme make bad developers.
Mateusz Jakub wrote:
Some just run for shiny new frameworks, some dig trenches around their favourite tools.
Very accurate observation.
-
There's definitely something of a cargo cult built around some methodologies. I recently worked with an ardent TDD disciple who would get a little upset with my view that TDD might have its place but that it wasn't the panacea for all things. I didn't get to see any of his work until after he left. Sure, all the unit tests were passed, but sadly, it wasn't quite the same story when it came to user tests. In fact, it couldn't have been more different. Everything was about as dysfunctional as it could possibly be. There's a dangerous belief at work there, namely: "I am doing this properly so I have no need to worry about anything going wrong." It's every bit as ill-founded as the idea that if we build the runway, the great iron bird will arrive laden with goodies, and its equally fallacious in that it comes with that implicit guarantee - "this is the way and the way cannot fail." Once we remove the possibility of failure from our expected outcomes (probably something that various new age barkers would actually advocate), we're left in a state where we stop thinking about how we'll deal with the inevitable. Rather than planning how we'll bubble up our exceptions, we just shrug our shoulders and say "Exceptions? What exceptions? There won't be any exceptions!" It's this complacency that tends to make rigid devotion to a methodology a very dangerous thing. The wise course is to cherry pick these things to suit our projects. A few core unit tests are obviously a good idea in many situations, so let's use them but the minute that we start to think that we've come across a fool-proof way to write bug-free software, we're off in the woods with the fairies and the unicorns and we haven't got a cat in hell's chance of coming back in one piece.
98.4% of statistics are made up on the spot.
That's more or less what I'm advocating. I simply don't believe that any methodology is one-size-fits-all. There are a couple of methodologies out there that suggest reasonable goals. I view these goals as aspirational. I make an honest effort to achieve them. However, if I find some goal is a bad fit for a specific project, I'm willing to set aside that goal. In general, I'm very leery of words like "always" and "never". In my experience these words are always wrong and never lead to good things :) As an example, I'm a huge believer in TDD. This is mostly because its saved my bacon more than a few times. Though, I think even it has some limitations. For example, during the initiation phase, I often like to prototype a couple of ideas first, before committing to an approach. I've had TDD purists complain that I'm doing it wrong, because I defer writing the tests (slightly) until after I choose the best approach.
-
That's more or less what I'm advocating. I simply don't believe that any methodology is one-size-fits-all. There are a couple of methodologies out there that suggest reasonable goals. I view these goals as aspirational. I make an honest effort to achieve them. However, if I find some goal is a bad fit for a specific project, I'm willing to set aside that goal. In general, I'm very leery of words like "always" and "never". In my experience these words are always wrong and never lead to good things :) As an example, I'm a huge believer in TDD. This is mostly because its saved my bacon more than a few times. Though, I think even it has some limitations. For example, during the initiation phase, I often like to prototype a couple of ideas first, before committing to an approach. I've had TDD purists complain that I'm doing it wrong, because I defer writing the tests (slightly) until after I choose the best approach.
Eric Lynch wrote:
In general, I'm very leery of words like "always" and "never". In my experience these words are always wrong and never lead to good things :)
That is a very healthy philosophy!
98.4% of statistics are made up on the spot.
-
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu. Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair. I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one. So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass. So, anyhow, here goes...ranting powers activate... I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge. They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah! Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off. OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad! I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant. "You can't do it that way." Why? Because, the methodology says its wrong. My favorite example is the Manifesto for Agile Software Development (http://agilemanifesto.org/). We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes. However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us. Step 1: Save the World - Some people with good intentions, recog
The problem with software methodologies occurs when the developers and the managers do not have the same goals. * You see agile introduced into a workplace by developers when the devs are tired of being chained to a heavyweight process with tons of useless meetings and an impossible schedule. * You see agile introduced by management when code is not always delivered on schedule, and when marketing doesn't always get that hot feature requested by a potential customer last week. Trying to get predictable delivery AND a sane process AND more emphasis on quality than quantity is difficult. Unless authority is shared between developers and managers, it rarely works out well.
-
Been there and had those discussions. Once, I had a meeting to discuss the schedule and agenda for another meeting. Sometimes it amazes me that any actual work ever gets done :)
-
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu. Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair. I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one. So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass. So, anyhow, here goes...ranting powers activate... I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge. They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah! Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off. OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad! I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant. "You can't do it that way." Why? Because, the methodology says its wrong. My favorite example is the Manifesto for Agile Software Development (http://agilemanifesto.org/). We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes. However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us. Step 1: Save the World - Some people with good intentions, recog
I agree with some of the posters. I have seen quite a few methodologies and the frustrating thing I see, especially as it relates to agile, is that everybody believes it solves all software problems but they don't really understand what they are. Agile development is a method of development of software, not a method of everything. As an example, if I give you a cow and a tree and tell you to build a teepee, you end up short of a few things. How do I get cow hide? How do I get poles? How do I build the teepee? Do I have to fit it for one person? Yeah, that list could go on forever, but I think it makes the point. You have to do the basics. You have to do the analysis. You have to do the requirements gathering. You have to define testing, if you want to test? How? Unit testing only? Again, that list can go on forever. In my experience the industry, and quite literally every job I have worked at in a decade, goes "we are doing agile application development, here is the customers old database it is 20 years old, you have to build a new modern database from it. You also have to modernize it, use all these new technologies and make it shiny. Oh and you can't talk to the customer." They then expect agile to just cover the development, not have any problems and make a perfect product without even finding out what the clients current needs are. It is ridiculous and it shows how the actual concepts of software development are dying to a culture of fads and not actually using the thing between your ears.
-
I agree with some of the posters. I have seen quite a few methodologies and the frustrating thing I see, especially as it relates to agile, is that everybody believes it solves all software problems but they don't really understand what they are. Agile development is a method of development of software, not a method of everything. As an example, if I give you a cow and a tree and tell you to build a teepee, you end up short of a few things. How do I get cow hide? How do I get poles? How do I build the teepee? Do I have to fit it for one person? Yeah, that list could go on forever, but I think it makes the point. You have to do the basics. You have to do the analysis. You have to do the requirements gathering. You have to define testing, if you want to test? How? Unit testing only? Again, that list can go on forever. In my experience the industry, and quite literally every job I have worked at in a decade, goes "we are doing agile application development, here is the customers old database it is 20 years old, you have to build a new modern database from it. You also have to modernize it, use all these new technologies and make it shiny. Oh and you can't talk to the customer." They then expect agile to just cover the development, not have any problems and make a perfect product without even finding out what the clients current needs are. It is ridiculous and it shows how the actual concepts of software development are dying to a culture of fads and not actually using the thing between your ears.
Regrettably, so many different methodologies currently claim to be "agile" that the word has almost lost all meaning. For example, the original (from Manifesto for Agile Software Development[^]) actually favors customer collaboration. It sounds like you've fallen victim to one of the variants where the engineering team is discouraged from communicating with the customer. I've been there...not much fun. Unfortunately, this seems to be the norm with most of the variants claiming to be "agile".
-
From my 20+years of IT/software work the methodologies used don't appear to have had a huge impact on the outcome. The one thing that has determined the success/failure of projects I have worked on has been the quality of communication between people in the team. Where there has been a culture of people not talking to each other or screaming and swearing/threatening each other the outcome has generally been fairly poor. Whereas when the has been a more friendly and supportive/mentoring culture the outcome of projects has generally always been one of success. So my experience tells me that it's not necessarily the methodology that counts but the quality of communication between people in a team/business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
The one thing that has determined the success/failure of projects I have worked on has been the quality of communication between people in the team.
It's interesting you mention that. I say that because have you heard what one of the guys that came up with agile wanted to call it instead of agile? Conversational development, IE the way you do anything is to have a conversation between the involved individuals. Of course it also has to be stated that you can't have a conversation if one side doesn't respect the other, in that case you generally end up with a lecture. Unfortunately with a name like "Agile" plus all that dogma in the manifesto the core idea which you've hit upon gets lost doesn't it?
