Agile development
-
So I just finished reading a few articles on Agile (until now I've only known of it's existance and knew it was a new approach to sotfware development, but cared or knew little more about it) development. I must say I rather enjoyed hearing all that I read. As a self taught programmer I have had very little standards influence in anything i have done, but I have made leaps and bounds in many areas in the last 2-3 years (slowly accepting web accessibility, design patterns, generating API docs using tools, TDD, etc). Agile is nothing like that I suspected it would be. I love it!!! I've never worked on a team before, only developed software by myself, mostly for myself...so the concept of pair programming (XP) is somewhat foriegn and even still I would argue somewhat redundant and the negatives would outweigh the positives. I plan on focusing more and more efforts on remote team develpment (people from various parts of the world working simultanesouly on a single project) so perhaps this is causing me to see pair programming biasedly (is that even a word :P ) Lately I have been putting a lot of thought into the different organizational levels of software development and can see connections being made left right and center between project managament, software development and source code organization and more... I must say, the more I learn about one level, the clearer the picture becomes for the next and vis-versa. The concepts of design patterns, despite having read up on them the most lately, is really starting to make sense. Design patterns are forcing me to think abstractly in many cases which is assisting me in seeing the whole scheme of things. TDD came very natural to me, as even a self taught developer I liked to really plan out an object API before implementing it. But I've never been a fan of putting much effort into overall planning or documentation (as even on a personal level - the docs I'd write up for an app would be *completely* different then what the project looked like when finished) so Agile development is kind of like a pat on the back, asserting that what I was doing by default was the better approach to software development. A few years back I bought a book which introduced me to a more formalized development, waterfall, iterative, etc...but it was a dry read at the time and I kind of dropped it, but atleast gained insight into possible plans of attack on developing software. Despite my software practices being somewhat Agile, they were likely more chaotic in nature. :P Most
require loose adherence to all of their principles except unit testing. Every thing else needs to be adapted to fit your exact situation. Personally I am getting tired of methodology for sake of methodology. I am starting to see a significant decline in the quality of production code but it follows "standards and practices"!
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage
-
So I just finished reading a few articles on Agile (until now I've only known of it's existance and knew it was a new approach to sotfware development, but cared or knew little more about it) development. I must say I rather enjoyed hearing all that I read. As a self taught programmer I have had very little standards influence in anything i have done, but I have made leaps and bounds in many areas in the last 2-3 years (slowly accepting web accessibility, design patterns, generating API docs using tools, TDD, etc). Agile is nothing like that I suspected it would be. I love it!!! I've never worked on a team before, only developed software by myself, mostly for myself...so the concept of pair programming (XP) is somewhat foriegn and even still I would argue somewhat redundant and the negatives would outweigh the positives. I plan on focusing more and more efforts on remote team develpment (people from various parts of the world working simultanesouly on a single project) so perhaps this is causing me to see pair programming biasedly (is that even a word :P ) Lately I have been putting a lot of thought into the different organizational levels of software development and can see connections being made left right and center between project managament, software development and source code organization and more... I must say, the more I learn about one level, the clearer the picture becomes for the next and vis-versa. The concepts of design patterns, despite having read up on them the most lately, is really starting to make sense. Design patterns are forcing me to think abstractly in many cases which is assisting me in seeing the whole scheme of things. TDD came very natural to me, as even a self taught developer I liked to really plan out an object API before implementing it. But I've never been a fan of putting much effort into overall planning or documentation (as even on a personal level - the docs I'd write up for an app would be *completely* different then what the project looked like when finished) so Agile development is kind of like a pat on the back, asserting that what I was doing by default was the better approach to software development. A few years back I bought a book which introduced me to a more formalized development, waterfall, iterative, etc...but it was a dry read at the time and I kind of dropped it, but atleast gained insight into possible plans of attack on developing software. Despite my software practices being somewhat Agile, they were likely more chaotic in nature. :P Most
I don't know why you got a 1 vote, because frankly, I think it's absolutely fantastic that you're thinking about these things and that you're interesting in reading about different methodologies, etc. Good for you, I say! IMO, agile doesn't eliminate planning at all. It does however break down planning into much smaller pieces, pieces that can be turned around quickly for the customer to review. Agile emphasizes unit testing as a direct result of the plan, so that when some part of the big plan changes, you can make sure all your little plans are still working. Agile also attempts to do something that is pretty much a failure in this industry--software development metrics. It becomes possible to determine how well the team is doing with each plan element, and to make adjustments in schedules, estimation, etc. If you do agile right, you'd notice the schedule slips sooner, I think, because a lot of things are broken down into one day efforts, rather than "here's a task we estimate will take 2 weeks (or 3 months!), go do it". But Agile exposes people's deficiencies very quickly, not just programmers, but the client's (communicating requirements), management's (being able to drive the team and have those daily stand up meetings), the programmer's (idiotic code). It can be stressful, you can't hide your weaknesses, and you need a group that isn't internally competetive--so often programmers are against each other. With Agile, you have to be working together, honestly, openly, transparently, and I think good people skills is a necessity, something programmers often lack. [edit]What I don't like about Agile is that people see it as a way to de-emphasize good up front design, leaving it to be refactored later on. Refactoring should NOT be used for reworking architecture, IMO. That's called "rewrite". If design is what you mean by "plan", then yes, I'd agree with you, that Agile comes across as being less designed. That is its failing, IMO.[/edit] Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
So I just finished reading a few articles on Agile (until now I've only known of it's existance and knew it was a new approach to sotfware development, but cared or knew little more about it) development. I must say I rather enjoyed hearing all that I read. As a self taught programmer I have had very little standards influence in anything i have done, but I have made leaps and bounds in many areas in the last 2-3 years (slowly accepting web accessibility, design patterns, generating API docs using tools, TDD, etc). Agile is nothing like that I suspected it would be. I love it!!! I've never worked on a team before, only developed software by myself, mostly for myself...so the concept of pair programming (XP) is somewhat foriegn and even still I would argue somewhat redundant and the negatives would outweigh the positives. I plan on focusing more and more efforts on remote team develpment (people from various parts of the world working simultanesouly on a single project) so perhaps this is causing me to see pair programming biasedly (is that even a word :P ) Lately I have been putting a lot of thought into the different organizational levels of software development and can see connections being made left right and center between project managament, software development and source code organization and more... I must say, the more I learn about one level, the clearer the picture becomes for the next and vis-versa. The concepts of design patterns, despite having read up on them the most lately, is really starting to make sense. Design patterns are forcing me to think abstractly in many cases which is assisting me in seeing the whole scheme of things. TDD came very natural to me, as even a self taught developer I liked to really plan out an object API before implementing it. But I've never been a fan of putting much effort into overall planning or documentation (as even on a personal level - the docs I'd write up for an app would be *completely* different then what the project looked like when finished) so Agile development is kind of like a pat on the back, asserting that what I was doing by default was the better approach to software development. A few years back I bought a book which introduced me to a more formalized development, waterfall, iterative, etc...but it was a dry read at the time and I kind of dropped it, but atleast gained insight into possible plans of attack on developing software. Despite my software practices being somewhat Agile, they were likely more chaotic in nature. :P Most
Better read Joel's latest post on Agile[^]. Or rather, Stevey's blog post on agile. My thoughts: agile development was an over-hyped fad, but some good things sprang to the fore because of it: unit testing, continual refactoring, and "release early and often" kind of thinking. Some of the dumb things about agile: pair programming, the whole index card thing, the hype.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: For Christians: The Significance of Yom Teruah The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
I don't know why you got a 1 vote, because frankly, I think it's absolutely fantastic that you're thinking about these things and that you're interesting in reading about different methodologies, etc. Good for you, I say! IMO, agile doesn't eliminate planning at all. It does however break down planning into much smaller pieces, pieces that can be turned around quickly for the customer to review. Agile emphasizes unit testing as a direct result of the plan, so that when some part of the big plan changes, you can make sure all your little plans are still working. Agile also attempts to do something that is pretty much a failure in this industry--software development metrics. It becomes possible to determine how well the team is doing with each plan element, and to make adjustments in schedules, estimation, etc. If you do agile right, you'd notice the schedule slips sooner, I think, because a lot of things are broken down into one day efforts, rather than "here's a task we estimate will take 2 weeks (or 3 months!), go do it". But Agile exposes people's deficiencies very quickly, not just programmers, but the client's (communicating requirements), management's (being able to drive the team and have those daily stand up meetings), the programmer's (idiotic code). It can be stressful, you can't hide your weaknesses, and you need a group that isn't internally competetive--so often programmers are against each other. With Agile, you have to be working together, honestly, openly, transparently, and I think good people skills is a necessity, something programmers often lack. [edit]What I don't like about Agile is that people see it as a way to de-emphasize good up front design, leaving it to be refactored later on. Refactoring should NOT be used for reworking architecture, IMO. That's called "rewrite". If design is what you mean by "plan", then yes, I'd agree with you, that Agile comes across as being less designed. That is its failing, IMO.[/edit] Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
so often programmers are against each other
I've noticed :P I've never worked in a team environment, but with the experiences I've had online (here and others) I honestly think sometimes people just argue for the sake of arguing... I don't mind being wrong, infact, I learn best that way. I actually hate it, so being proved wrong reaffirms the opposite of what I originally thought, if that makes anysense :P Basically once proved wrong, I'll never forget it, so instead of having to read something 3 or 4 times to absorb it fully, I usually take in everything in round one when someone can show me where I went wrong.
Marc Clifton wrote:
What I don't like about Agile is that people see it as a way to de-emphasize good up front design
Not sure I follow you by upfront design? :( Are you saying the overall architecture of a software system would be considered upfront design? Hmmm...in your experience, what would you define as the phase of initial planning and design? 1) Specification would be a first phase I imagine 2) Very high level abstractions or systems - lines indicating communication/connection, etc 3) design pattern phase 4) algorithms 5) Implementation - psudeocode level It's the core or implementation level which I was refering to when I said Agile IMHO would make sense, but higher levels of abstraction wouldn't make sense to use Agile. From what I can tell there are two categories of which all SDLC environments can fall under: 1) Static SDLC environment 2) Dynamic SDLC environment Static would be used in cases where applications are critical, like real-time processing, automation (auto pilots, missle navigation, brain scan, etc). The specification here would need to be finite and clearly declared before anything goes forward. Dynamic on the other hand would be more geared towards business application development as business is like a football game or battle zone, your business needs to adapt to it's environment and thus features in an application are volatile. In this case I can see how Agile principles and practices make *alot* of sense. Does this make sense? Thanks for the input Marc, it's your infleunce that got me into Agile in the first place, so I owe you one. ;) p.s-Pardon me if this totally doesn't make sense, but I'm really just brain dumping ideas and concepts from my current level of understanding. Cheers :)
-
Better read Joel's latest post on Agile[^]. Or rather, Stevey's blog post on agile. My thoughts: agile development was an over-hyped fad, but some good things sprang to the fore because of it: unit testing, continual refactoring, and "release early and often" kind of thinking. Some of the dumb things about agile: pair programming, the whole index card thing, the hype.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: For Christians: The Significance of Yom Teruah The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Although I can't say (currently) pair programming appeals to me... I have no idea what index card is about...and hype...well hype is of no fault of Agile or XP, etc...but rather overly zealous people :P Just because something gets alot of hype or attention doesn't make it a bad thing...it's how you deal or separate the fact from fiction, fad from functionality and so on... My biggest hurdle in reading anything about it, was pure arrogance...thinking I've developed software fine in the past, why would I need to change? Then the answer kinda clicked :) Why do we switch from procedural to OOP or from Assembly to high level languages... Why do so many embrace .NET (It's a personal vendetta against Microsoft that prevents me from going any further with it). IMHO it's not a fad or the latest fashion full of buzzwords, it's simply a different approach to what many of us are used to and people are hard pressed to change what they know. It's benefits are simply less obvious than say switching from assmebly to C...and perhaps it carries equal number of disadvantages, but I can't say as I'm just starting to read about it... One thing for sure, if your not en expert in Agile, XP, etc...no one really has any place saying it's a fad or useless of just industry buzz. Because then it's obvious to me anyways, you simply don't understand what it is... An expert in both would not claim such a thing, but rather offer a point by point comparison of the advantages and disadvantages of both. Fad is a strong word...I've seen an increase in popularity in the PHP and Javascript community...so I seriously dought it is a fad :P Cheers :)
It's frustrating being a genius and living the life of a moron!!!
-
Although I can't say (currently) pair programming appeals to me... I have no idea what index card is about...and hype...well hype is of no fault of Agile or XP, etc...but rather overly zealous people :P Just because something gets alot of hype or attention doesn't make it a bad thing...it's how you deal or separate the fact from fiction, fad from functionality and so on... My biggest hurdle in reading anything about it, was pure arrogance...thinking I've developed software fine in the past, why would I need to change? Then the answer kinda clicked :) Why do we switch from procedural to OOP or from Assembly to high level languages... Why do so many embrace .NET (It's a personal vendetta against Microsoft that prevents me from going any further with it). IMHO it's not a fad or the latest fashion full of buzzwords, it's simply a different approach to what many of us are used to and people are hard pressed to change what they know. It's benefits are simply less obvious than say switching from assmebly to C...and perhaps it carries equal number of disadvantages, but I can't say as I'm just starting to read about it... One thing for sure, if your not en expert in Agile, XP, etc...no one really has any place saying it's a fad or useless of just industry buzz. Because then it's obvious to me anyways, you simply don't understand what it is... An expert in both would not claim such a thing, but rather offer a point by point comparison of the advantages and disadvantages of both. Fad is a strong word...I've seen an increase in popularity in the PHP and Javascript community...so I seriously dought it is a fad :P Cheers :)
It's frustrating being a genius and living the life of a moron!!!
Yeah, maybe fad isn't the right word. Like I said, lots of useful things have been gleened from agile programming methods. Maybe over-hyped methodology would be a better term. p.s. I'd also say the current hype surrounding Ruby, Python, and friends falls into the same over-hyped methodology as AP/XP.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: For Christians: The Significance of Yom Teruah The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Marc Clifton wrote:
so often programmers are against each other
I've noticed :P I've never worked in a team environment, but with the experiences I've had online (here and others) I honestly think sometimes people just argue for the sake of arguing... I don't mind being wrong, infact, I learn best that way. I actually hate it, so being proved wrong reaffirms the opposite of what I originally thought, if that makes anysense :P Basically once proved wrong, I'll never forget it, so instead of having to read something 3 or 4 times to absorb it fully, I usually take in everything in round one when someone can show me where I went wrong.
Marc Clifton wrote:
What I don't like about Agile is that people see it as a way to de-emphasize good up front design
Not sure I follow you by upfront design? :( Are you saying the overall architecture of a software system would be considered upfront design? Hmmm...in your experience, what would you define as the phase of initial planning and design? 1) Specification would be a first phase I imagine 2) Very high level abstractions or systems - lines indicating communication/connection, etc 3) design pattern phase 4) algorithms 5) Implementation - psudeocode level It's the core or implementation level which I was refering to when I said Agile IMHO would make sense, but higher levels of abstraction wouldn't make sense to use Agile. From what I can tell there are two categories of which all SDLC environments can fall under: 1) Static SDLC environment 2) Dynamic SDLC environment Static would be used in cases where applications are critical, like real-time processing, automation (auto pilots, missle navigation, brain scan, etc). The specification here would need to be finite and clearly declared before anything goes forward. Dynamic on the other hand would be more geared towards business application development as business is like a football game or battle zone, your business needs to adapt to it's environment and thus features in an application are volatile. In this case I can see how Agile principles and practices make *alot* of sense. Does this make sense? Thanks for the input Marc, it's your infleunce that got me into Agile in the first place, so I owe you one. ;) p.s-Pardon me if this totally doesn't make sense, but I'm really just brain dumping ideas and concepts from my current level of understanding. Cheers :)
Hockey wrote:
Not sure I follow you by upfront design?
Forgive me for butting in :) I think what Marc is getting at is that some people / orgs preach 'emergent design' of the product. The practice can be likened to not having a lot of details of the implementation planned and allowing the 'design' of the system to emerge as your hit your milestones.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long, Time Enough For Love
-
Yeah, maybe fad isn't the right word. Like I said, lots of useful things have been gleened from agile programming methods. Maybe over-hyped methodology would be a better term. p.s. I'd also say the current hype surrounding Ruby, Python, and friends falls into the same over-hyped methodology as AP/XP.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: For Christians: The Significance of Yom Teruah The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
I'd also say the current hype surrounding Ruby, Python, and friends
Is Pyhton getting hyped again? Maybe I missed something. I will say it is a damn fine scripting language. I've been coding Pyhton professionaly since 2001 for various clients and employers. Maybe I am just immue to the new hype. I won't preach that it belongs everywhere but it is super productive as a glue language when working on extreamly large projects. Heck I already shipped a beta application using IronPython to handle the client side scripting "stuff" on a C# project. I'd love to share what our team has done, but a few NDAs keep me from saying much.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long, Time Enough For Love
-
So I just finished reading a few articles on Agile (until now I've only known of it's existance and knew it was a new approach to sotfware development, but cared or knew little more about it) development. I must say I rather enjoyed hearing all that I read. As a self taught programmer I have had very little standards influence in anything i have done, but I have made leaps and bounds in many areas in the last 2-3 years (slowly accepting web accessibility, design patterns, generating API docs using tools, TDD, etc). Agile is nothing like that I suspected it would be. I love it!!! I've never worked on a team before, only developed software by myself, mostly for myself...so the concept of pair programming (XP) is somewhat foriegn and even still I would argue somewhat redundant and the negatives would outweigh the positives. I plan on focusing more and more efforts on remote team develpment (people from various parts of the world working simultanesouly on a single project) so perhaps this is causing me to see pair programming biasedly (is that even a word :P ) Lately I have been putting a lot of thought into the different organizational levels of software development and can see connections being made left right and center between project managament, software development and source code organization and more... I must say, the more I learn about one level, the clearer the picture becomes for the next and vis-versa. The concepts of design patterns, despite having read up on them the most lately, is really starting to make sense. Design patterns are forcing me to think abstractly in many cases which is assisting me in seeing the whole scheme of things. TDD came very natural to me, as even a self taught developer I liked to really plan out an object API before implementing it. But I've never been a fan of putting much effort into overall planning or documentation (as even on a personal level - the docs I'd write up for an app would be *completely* different then what the project looked like when finished) so Agile development is kind of like a pat on the back, asserting that what I was doing by default was the better approach to software development. A few years back I bought a book which introduced me to a more formalized development, waterfall, iterative, etc...but it was a dry read at the time and I kind of dropped it, but atleast gained insight into possible plans of attack on developing software. Despite my software practices being somewhat Agile, they were likely more chaotic in nature. :P Most
I'd reccomend you pick up Coder to Developer by Mike Gunderloy. There is a nice short chapter on methodoligies. But his core message is nice and simple. Use what works for you and throw out the rest.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long, Time Enough For Love
-
So I just finished reading a few articles on Agile (until now I've only known of it's existance and knew it was a new approach to sotfware development, but cared or knew little more about it) development. I must say I rather enjoyed hearing all that I read. As a self taught programmer I have had very little standards influence in anything i have done, but I have made leaps and bounds in many areas in the last 2-3 years (slowly accepting web accessibility, design patterns, generating API docs using tools, TDD, etc). Agile is nothing like that I suspected it would be. I love it!!! I've never worked on a team before, only developed software by myself, mostly for myself...so the concept of pair programming (XP) is somewhat foriegn and even still I would argue somewhat redundant and the negatives would outweigh the positives. I plan on focusing more and more efforts on remote team develpment (people from various parts of the world working simultanesouly on a single project) so perhaps this is causing me to see pair programming biasedly (is that even a word :P ) Lately I have been putting a lot of thought into the different organizational levels of software development and can see connections being made left right and center between project managament, software development and source code organization and more... I must say, the more I learn about one level, the clearer the picture becomes for the next and vis-versa. The concepts of design patterns, despite having read up on them the most lately, is really starting to make sense. Design patterns are forcing me to think abstractly in many cases which is assisting me in seeing the whole scheme of things. TDD came very natural to me, as even a self taught developer I liked to really plan out an object API before implementing it. But I've never been a fan of putting much effort into overall planning or documentation (as even on a personal level - the docs I'd write up for an app would be *completely* different then what the project looked like when finished) so Agile development is kind of like a pat on the back, asserting that what I was doing by default was the better approach to software development. A few years back I bought a book which introduced me to a more formalized development, waterfall, iterative, etc...but it was a dry read at the time and I kind of dropped it, but atleast gained insight into possible plans of attack on developing software. Despite my software practices being somewhat Agile, they were likely more chaotic in nature. :P Most
I have a very negative view of Agile and XP programming. Each has some good points wrapped in a whole lot of bullshit. From my own experience, rather than make software better design, I've seen both used as an excuse to do less planning. What bugged me the most were how many important questions were simply not dealt with since "we hadn't gotten there yet." Worse, when pressed about deadlines the answer is a shrug or some overaggresive nonsense. The real irony is that many of the places that claim to do Agile/XP programming really do nothing of the sort except those very few good ideas that they used to do anyway, but which have been co-opted.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Marc Clifton wrote:
so often programmers are against each other
I've noticed :P I've never worked in a team environment, but with the experiences I've had online (here and others) I honestly think sometimes people just argue for the sake of arguing... I don't mind being wrong, infact, I learn best that way. I actually hate it, so being proved wrong reaffirms the opposite of what I originally thought, if that makes anysense :P Basically once proved wrong, I'll never forget it, so instead of having to read something 3 or 4 times to absorb it fully, I usually take in everything in round one when someone can show me where I went wrong.
Marc Clifton wrote:
What I don't like about Agile is that people see it as a way to de-emphasize good up front design
Not sure I follow you by upfront design? :( Are you saying the overall architecture of a software system would be considered upfront design? Hmmm...in your experience, what would you define as the phase of initial planning and design? 1) Specification would be a first phase I imagine 2) Very high level abstractions or systems - lines indicating communication/connection, etc 3) design pattern phase 4) algorithms 5) Implementation - psudeocode level It's the core or implementation level which I was refering to when I said Agile IMHO would make sense, but higher levels of abstraction wouldn't make sense to use Agile. From what I can tell there are two categories of which all SDLC environments can fall under: 1) Static SDLC environment 2) Dynamic SDLC environment Static would be used in cases where applications are critical, like real-time processing, automation (auto pilots, missle navigation, brain scan, etc). The specification here would need to be finite and clearly declared before anything goes forward. Dynamic on the other hand would be more geared towards business application development as business is like a football game or battle zone, your business needs to adapt to it's environment and thus features in an application are volatile. In this case I can see how Agile principles and practices make *alot* of sense. Does this make sense? Thanks for the input Marc, it's your infleunce that got me into Agile in the first place, so I owe you one. ;) p.s-Pardon me if this totally doesn't make sense, but I'm really just brain dumping ideas and concepts from my current level of understanding. Cheers :)
Hockey wrote:
I honestly think sometimes people just argue for the sake of arguing...
I am not sure I would agree with that, you might be wrong ;) Kidding ;) One quick note in "agile" development is often the client does not even know what they really want, so any requirements you gather may not really be the target. With iterative development, the client gets a better idea of where the project is heading sooner and less likely to require major code changes as it would to be caught later on in the game. I am sure most of us have known a situation when all the requirements were gathered up front and all the design laid out before the code even began only to find that once the finished (subject to interpretation :) ) product was delivered the client got just what they asked for but not what they needed. Back in the 90s, quite a few people believed in full design up front and considered something such as iterative development sloppy or lacking in design. The heart of the situation though is that none of these methodologies will fit every project, you have to pick or blend to fit the situation at hand. Continued learning simply enlarges your tool box and means you no longer have to use a hammer for everything ;)
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Microsoft Zune to be built by Toshiba
-
Hockey wrote:
Not sure I follow you by upfront design?
Forgive me for butting in :) I think what Marc is getting at is that some people / orgs preach 'emergent design' of the product. The practice can be likened to not having a lot of details of the implementation planned and allowing the 'design' of the system to emerge as your hit your milestones.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long, Time Enough For Love
Chris Austin wrote:
I think what Marc is getting at is that some people / orgs preach 'emergent design' of the product.
Quite well said! Thanks! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Yeah, maybe fad isn't the right word. Like I said, lots of useful things have been gleened from agile programming methods. Maybe over-hyped methodology would be a better term. p.s. I'd also say the current hype surrounding Ruby, Python, and friends falls into the same over-hyped methodology as AP/XP.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: For Christians: The Significance of Yom Teruah The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Perhaps, but Ruby and Python are langauges which require learning yet another programming langauge, when PHP does me just fine for web development and I would argue most PHP developers would agree... Agile/XP can be applied to any number of langauges (PHP, Javascript, C++ and so on) so it's worth learning if your a developer who programs frequently in more than one language. Ruby is getting alot of attention because of it's RAD capabilities...not so much it's Ruby as a language itself, although from what I can tell it's only capable of doing so because of the language itself. Although this can be emulated in PHP, look into CakePHP which I believe is a Ruby on Rails knock off of sorts. \ Cheers :)
It's frustrating being a genius and living the life of a moron!!!
-
I have a very negative view of Agile and XP programming. Each has some good points wrapped in a whole lot of bullshit. From my own experience, rather than make software better design, I've seen both used as an excuse to do less planning. What bugged me the most were how many important questions were simply not dealt with since "we hadn't gotten there yet." Worse, when pressed about deadlines the answer is a shrug or some overaggresive nonsense. The real irony is that many of the places that claim to do Agile/XP programming really do nothing of the sort except those very few good ideas that they used to do anyway, but which have been co-opted.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
In my experience, i have found that you need to mix and match parts of different methodologies to suit your environment / situation. To use one exclusively is counter-productive. I prefer to initially approach a project with traditional project life-cycle and implementation methodolodies in order to get a very good and accurate idea of how the project will flow. This is important in a real-world environment because of clients. Clients have a vague idea of what they need, sometimes the only thing they know is that they need a new system based on the fact that the old one is either too slow or just doesnt work very well for them. First and foremost then it is important to analyse their situation and project plan so that you can present to the client and let them know what you think will benefit them the most and how long that will take. Along with this you introduce the idea of pseudo Agile in the sense that you make the client aware that things arent cast in stone once they give sign-off but at the same time they need to understand that they will be responsible for funding the changes in mid-execution. As far as i'm concerned Agile is only beneficial to the client or the architecht who has made a blunder.(it happens) XP is marvelous when you need to quickly write a fantastic algorythm. Two heads are better than one. But for normal 'construction / brick and mortar' programming XP is counter-productive. --- The world is the mollusc of your choice.
-
Hockey wrote:
I honestly think sometimes people just argue for the sake of arguing...
I am not sure I would agree with that, you might be wrong ;) Kidding ;) One quick note in "agile" development is often the client does not even know what they really want, so any requirements you gather may not really be the target. With iterative development, the client gets a better idea of where the project is heading sooner and less likely to require major code changes as it would to be caught later on in the game. I am sure most of us have known a situation when all the requirements were gathered up front and all the design laid out before the code even began only to find that once the finished (subject to interpretation :) ) product was delivered the client got just what they asked for but not what they needed. Back in the 90s, quite a few people believed in full design up front and considered something such as iterative development sloppy or lacking in design. The heart of the situation though is that none of these methodologies will fit every project, you have to pick or blend to fit the situation at hand. Continued learning simply enlarges your tool box and means you no longer have to use a hammer for everything ;)
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Microsoft Zune to be built by Toshiba
Gee, I thougth that was called 'programming'... Iterative development is what I've been doing for the last 20 years, no matter what the tool, it's a methodology, not something that comes in a package. I have never seen a piece of software that was of any significance (developed in assembler, cobol, fortran, old basics, c, c++, c#, asp, vb vb.net, lisp, algo, modula, python, etc...) that did not go through iteration after iteration both in development and with the inevitable change request, feature upgrades, re-design for a newer platform, etc. And yes, 99% of the time all of the requirements are not identified up front. The problem with many people in management is that they think they can order up software like a big mac and fries. What they don't realize is that in the un-real world of coding there are a whole lot of considerations. It's kind of like the company that models some sort of application/database in access. Sure it works with 100,000 rows but what happens when you scale it to 20,000,000 rows? It breaks, then you need to get out sql server or oracle or db2 or something that is designed for large scale, high volumn transaction processing. However, now the apps themselves won't work. So they have to be re-engineered. And finally, some genius bean counter wants to run everything off of a windows app server on the network because some smuck salesman told him he could save money that way. Never mind the extra money that has to be paid to the poor data entry person who has to wait 30 sec to a minute everytime they refresh the data... So you see, software development is always an iterative process, and it is an educational one too. Those of us who know technologies have to constantly save people like the poor bean counter from themselves. That in itself is an iterative process...
Regards, John McPherson "Sufficiently advanced technology is indistinguishable from magic." Arthur C. Clark, inventor of the telecommunications satellite
-
Gee, I thougth that was called 'programming'... Iterative development is what I've been doing for the last 20 years, no matter what the tool, it's a methodology, not something that comes in a package. I have never seen a piece of software that was of any significance (developed in assembler, cobol, fortran, old basics, c, c++, c#, asp, vb vb.net, lisp, algo, modula, python, etc...) that did not go through iteration after iteration both in development and with the inevitable change request, feature upgrades, re-design for a newer platform, etc. And yes, 99% of the time all of the requirements are not identified up front. The problem with many people in management is that they think they can order up software like a big mac and fries. What they don't realize is that in the un-real world of coding there are a whole lot of considerations. It's kind of like the company that models some sort of application/database in access. Sure it works with 100,000 rows but what happens when you scale it to 20,000,000 rows? It breaks, then you need to get out sql server or oracle or db2 or something that is designed for large scale, high volumn transaction processing. However, now the apps themselves won't work. So they have to be re-engineered. And finally, some genius bean counter wants to run everything off of a windows app server on the network because some smuck salesman told him he could save money that way. Never mind the extra money that has to be paid to the poor data entry person who has to wait 30 sec to a minute everytime they refresh the data... So you see, software development is always an iterative process, and it is an educational one too. Those of us who know technologies have to constantly save people like the poor bean counter from themselves. That in itself is an iterative process...
Regards, John McPherson "Sufficiently advanced technology is indistinguishable from magic." Arthur C. Clark, inventor of the telecommunications satellite
JohnMcPherson1 wrote:
I have never seen a piece of software that was of any significance (developed in assembler, cobol, fortran, old basics, c, c++, c#, asp, vb vb.net, lisp, algo, modula, python, etc...) that did not go through iteration after iteration both in development and with the inevitable change request, feature upgrades, re-design for a newer platform, etc.
Well, just about anything is iterative to a point, but what I am referring to is allowing those cycles to be much shorter so there is less waste designing and coding features that really do not work as expected. Short cycle iterative work such as 1,2 or 4 week cycles helps weed out problems before they get costly to change. This allows development to have greater flexibility. This is what I refer to as "Iterative development". Over the last twenty years, I have people say that you need to have the planning up front, follow through with the build and then submit for review. This has failed most of the time for those that I know, but if they had used shorter cycles (depending on project), they would know quickly if something works for a client or not.
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Windows Vista - My Journey begins!
-
JohnMcPherson1 wrote:
I have never seen a piece of software that was of any significance (developed in assembler, cobol, fortran, old basics, c, c++, c#, asp, vb vb.net, lisp, algo, modula, python, etc...) that did not go through iteration after iteration both in development and with the inevitable change request, feature upgrades, re-design for a newer platform, etc.
Well, just about anything is iterative to a point, but what I am referring to is allowing those cycles to be much shorter so there is less waste designing and coding features that really do not work as expected. Short cycle iterative work such as 1,2 or 4 week cycles helps weed out problems before they get costly to change. This allows development to have greater flexibility. This is what I refer to as "Iterative development". Over the last twenty years, I have people say that you need to have the planning up front, follow through with the build and then submit for review. This has failed most of the time for those that I know, but if they had used shorter cycles (depending on project), they would know quickly if something works for a client or not.
Rocky <>< Latest Code Blog Post: ASP.NET HttpException - Cannot use leading "..".. Latest Tech Blog Post: Windows Vista - My Journey begins!
That's exactly how I've been developing software, small steps... I've found that in many cases the cycle is as short as a day or even hours depending on the nature of the project. However, my average seems to be around a 1 to 2 week phase. I personally don't like projects that do not implement 'staged' deliverables. With staging (i.e. delivering features to test/users when they become available) one can more easily spot unwanted 'features', work flow compromises, un-anticipated side effects, etc. This allows for a better foundation to build the rest of the functionality into the software. Planning is a necessary phase however, it should be treated as a 'battle' plan. No battle plan has ever survived intact the initial strike and no software plan that I know of has ever survived the initial development phase intact. The plan is a guide to a path, it is not the path. So much for my soapbox today, I thank you for your response, have a great day...
Regards, John McPherson "Sufficiently advanced technology is indistinguishable from magic." Arthur C. Clark, inventor of the telecommunications satellite