SDLC, Agile, DevOps
-
I was reading this great article[^] on CP and it got me thinking: Isn't SDLC and Agile rather orthogonal, even in opposition with each other? And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both? What do you think? Are these "cult-ologies" compatible with each other?
Latest Articles:
DivWindow: Size, drag, minimize, and maximize floating windows with layout persistence -
I was reading this great article[^] on CP and it got me thinking: Isn't SDLC and Agile rather orthogonal, even in opposition with each other? And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both? What do you think? Are these "cult-ologies" compatible with each other?
Latest Articles:
DivWindow: Size, drag, minimize, and maximize floating windows with layout persistenceI suppose Agile is a series of Micro-SDLCs. DevOps is a meaningless buzzword.
-
I was reading this great article[^] on CP and it got me thinking: Isn't SDLC and Agile rather orthogonal, even in opposition with each other? And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both? What do you think? Are these "cult-ologies" compatible with each other?
Latest Articles:
DivWindow: Size, drag, minimize, and maximize floating windows with layout persistenceSDLC can be used as an overarching plan for the Agile development process, so long as you're willing to review both in light of new information and user needs. The fundamental weakness with SDLC is it doesn't handle requirements changes well. The fundamental weakness with Agile is the general lack of overall lifecycle thinking.
-
I was reading this great article[^] on CP and it got me thinking: Isn't SDLC and Agile rather orthogonal, even in opposition with each other? And I suppose DevOps is sort of one piece of both, but possibly also in conflict with both? What do you think? Are these "cult-ologies" compatible with each other?
Latest Articles:
DivWindow: Size, drag, minimize, and maximize floating windows with layout persistenceI've never had a high opinion of any of the formal software methodologies or their promoters. They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process. My group has run into this quite a bit, since we are a software group embedded in an engineering/R&D organization managed by mechanical engineers. The M.E.'s seem to be very fond of highly-detailed procedures for managing hardware development. I can see where these things work for them, but they're rarely applicable to software. At the moment we're fairly free of this nonsense. As long as we produce, they're leaving us alone.
Software Zen:
delete this; -
I've never had a high opinion of any of the formal software methodologies or their promoters. They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process. My group has run into this quite a bit, since we are a software group embedded in an engineering/R&D organization managed by mechanical engineers. The M.E.'s seem to be very fond of highly-detailed procedures for managing hardware development. I can see where these things work for them, but they're rarely applicable to software. At the moment we're fairly free of this nonsense. As long as we produce, they're leaving us alone.
Software Zen:
delete this;Gary R. Wheeler wrote:
They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT. DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC. We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! :)
-
Gary R. Wheeler wrote:
They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT. DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC. We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! :)
No question but that management fell for it.
-
SDLC can be used as an overarching plan for the Agile development process, so long as you're willing to review both in light of new information and user needs. The fundamental weakness with SDLC is it doesn't handle requirements changes well. The fundamental weakness with Agile is the general lack of overall lifecycle thinking.
Yeah, we just went to a weird flavor of agile and I've been clearly told that there is nothing but user stories. There is no overall design. I don't see it as a good thing, but that's not my problem ... or apparently anyone else's.
-
No question but that management fell for it.
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Software Zen:
delete this; -
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Software Zen:
delete this;That is the truth...
-
Gary R. Wheeler wrote:
They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT. DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC. We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! :)
Actually, it's a really tough problem to solve. How do you run a project that is part Artistic (requiring creativity), and Scientific, testable, repeatable, and educates the stakeholders as to the importance of their interacting and being available to the tech team trying to solve their problems? Also, how do you prevent "cave dwelling" coders from hiding in their caves, coming out with something they thrust on the users, based on what the users asked for? Having been around the industry for decades, and dabbling in management (but was a strong coder). I can see both sides. Furthermore, how do you manage this, when the complexity is huge? And how do you get consistent results? I don't think it was a grift, I think it was an attempt to COMMUNICATE the situation. The reason? Because we ended up developing our OWN version of XP as a natural approach to these problems. I found that Agile did a great job of codifying/naming the problems. But, we only used pair programming for training. We used code reviews over TDD (We limited testing code to class/libraries). While I saw some benefit to refactoring and TDD (and how it forced you to think FIRST as a CONSUMER of the functions, then the creator, but we did that naturally)... I could not justify the extra time/energy on all the test code. Leaning on code reviews was correct for us. Finally, we PUSHED the concepts of "Points of Contact" with business, and the REQUIREMENT that they be available, and that they be allowed to make decisions (oh the pushback. They wanted Jane to answer our questions, but not be able to decide without 5 meetings on every decisions, in case she had it wrong). I feel Agile helped the business people understand. You cannot withhold required information/decisions and demand we KEEP our deadlines! It's tough. There are a lot of decisions. There are a ton of impacts, and a lot of risks. Besides that, the developers were usually expensive resources to tie up. I can't blame anyone for working towards making it better than "Tell us what you want, and we will get back to you when we are done!"... LOL
-
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Software Zen:
delete this;Gary Wheeler wrote:
I think it's more a case of their susceptibility to the wiles of the Agile pimps than the developers got away with anything.
Ahhhh, the 'real' Agile Manifesto: We value: - Repeated mantras over proof of benefits. - Certification over knowledge, experience and talent. - Blind acceptance over a questioning mind. :omg:
-
Actually, it's a really tough problem to solve. How do you run a project that is part Artistic (requiring creativity), and Scientific, testable, repeatable, and educates the stakeholders as to the importance of their interacting and being available to the tech team trying to solve their problems? Also, how do you prevent "cave dwelling" coders from hiding in their caves, coming out with something they thrust on the users, based on what the users asked for? Having been around the industry for decades, and dabbling in management (but was a strong coder). I can see both sides. Furthermore, how do you manage this, when the complexity is huge? And how do you get consistent results? I don't think it was a grift, I think it was an attempt to COMMUNICATE the situation. The reason? Because we ended up developing our OWN version of XP as a natural approach to these problems. I found that Agile did a great job of codifying/naming the problems. But, we only used pair programming for training. We used code reviews over TDD (We limited testing code to class/libraries). While I saw some benefit to refactoring and TDD (and how it forced you to think FIRST as a CONSUMER of the functions, then the creator, but we did that naturally)... I could not justify the extra time/energy on all the test code. Leaning on code reviews was correct for us. Finally, we PUSHED the concepts of "Points of Contact" with business, and the REQUIREMENT that they be available, and that they be allowed to make decisions (oh the pushback. They wanted Jane to answer our questions, but not be able to decide without 5 meetings on every decisions, in case she had it wrong). I feel Agile helped the business people understand. You cannot withhold required information/decisions and demand we KEEP our deadlines! It's tough. There are a lot of decisions. There are a ton of impacts, and a lot of risks. Besides that, the developers were usually expensive resources to tie up. I can't blame anyone for working towards making it better than "Tell us what you want, and we will get back to you when we are done!"... LOL
I find that not one methodology fits for all needs, hence the need for various. SDLC, Agile, SCRUM, etc... depending on upper management and what they "understand" as being the methodology that will save them money is what they will implement and use/force down to us pawns. In my humble opinion, albeit all have their benefits, I think that the system chosen should be flexible to accommodate what you are managing. Production line manufacturing, down to simple app design for the latest in-style/market hype. Some may like agile boards to see where the stage of development is, yet others like Gantt charts, while still others like simple list of tasks completion and percentages with charts. For now, management will decide which we follow. This gives me an idea for an app.... :-O
-
Gary R. Wheeler wrote:
They all whiffed strongly of efforts by management to transform software development into a turn-the-crank process.
Actually, I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT. DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC. We'll soon be back to the days of hacking code on Production, with no spec! I remember them well - the 'good old days'! :)
5teveH wrote:
I think Agile is an attempt by techies to bluff management into thinking there's an easy way to do software development. And, unsurprisingly, management fell for it! It's been one of the most successful 'grifts' in IT. DevOps is now picking up the baton and trying to bluff management into thinking we don't need an SDLC.
That's the best definition of Agile and DevOps I've ever read! :thumbsup:
Latest Articles:
DivWindow: Size, drag, minimize, and maximize floating windows with layout persistence