csharpjava:

TDD is an important agile requirements and agile design technique.

Don't mix Test driven Development with unit testing, they are quite different.

csharpjava:


@Ghenghis  and delomos
Going by the answers you've given above I will not allow you to develop an internet banking application for me. The reason being that such an application would required that it is complete before being released for my customers to use. A Waterfall or an Iterative Watefall methodology is what will be required for an internet banking Application. The techniques you have mentioned are used for small releases so it is not suitable for an internet banking application that is being developed for the first time.

Its good you're not a bank then (I have developed internet banking apps for many banks ,   

Lets take GTBank for instance (I didn't develop that). If you've used their internet banking new features come out all the time. It started with :
balance inquiry facilities.
Self account transfers.
Within GTBank Transfers
GTbank to other account using NEFT
GTBank to other accounts using NIBBS Instant Payment etc.

Are you saying these functionality can't be delivered in phases ? (They were , ) Why do you think you know everything upfront ? the bank doesn't, CBN doesn't and NIBBS certainly don't(there are 2 very different versions of the same functionality)

delomos:

If you're designing an "academic" bank, your approach will work where most often you understand *all* the total requirement before you start building, in the real world, it doesn't work like so.

i agree

@Ghenghis and delomos

This thread is titled "In Search Of "that" Software Development Methodology" and I was expecting the discussions here to be based on solid software Engineering principles, but so far I have noticed that this has not been the case.
"A software development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system". Source: Wikipedia

csharpjava:

This thread is titled "In Search Of "that" Software Development Methodology" and I was expecting the discussions here to be based on solid software Engineering principles, but so far I have noticed that this has not been the case.

What does *solid* mean to you?

delomos:

What does *solid* mean to you?

You should not have started a thread titled "In Search Of "that" Software Development Methodology" which you have no clue about and you are not ready to learn. All your comments about software development here so far are techniques used in an Agile methodology. There are different Software Development Methodologies for different domains. So it is important you understand when and why you choose one methodology over the other. You cannot understand this unless you have a solid background in Software Engineering and this is the reason you have done nothing so far but disagree with me and cannot understand all my valuable contributions on this topic.

Ghenghis:

Don't mix Test driven Development with unit testing, they are quite different.
Its good you're not a bank then (I have developed internet banking apps for many banks ,   

TDD is a technique used in an agile methodology, it is one of "Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility." Source: Agile software development. You should note that techniques are not methodologies.

Ghenghis:

Lets take GTBank for instance (I didn't develop that). If you've used their internet banking new features come out all the time. It started with :
balance inquiry facilities.
Self account transfers.
Within GTBank Transfers
GTbank to other account using NEFT
GTBank to other accounts using NIBBS Instant Payment etc.

Are you saying these functionality can't be delivered in phases ? (They were , ) Why do you think you know everything upfront ? the bank doesn't, CBN doesn't and NIBBS certainly don't(there are 2 very different versions of the same functionality)

If your are developing an internet banking application for the first time then you cannot be delivering small releases, based on user stories. I will not want to wait for my customers to tell me that when they make a transfer, the money gets debited from their account but the recipient's account is not credited, then I will bring this new story to you and you will develop another small release for this new story. these are the kinds of factors you have to consider before selecting a methodology.

csharpjava:


If your are developing an internet banking application for the first time then you cannot be delivering small releases, based on user stories. I will not want to wait for my customers to tell me that when they make a transfer, the money gets debited from their account but the recipient's account is not credited, then I will bring this new story to you and you will develop another small release for this new story. these are the kinds of factors you have to consider before selecting a methodology.

An iteration usually has a recommended time frame (few weeks), what you do within iteration is a function of your teams size and run rate. You deliver complete use cases within iterations (Something the customer can test end to end). So debiting a customer is not one use case while crediting the recipient another.
If the debit cannot make sense without the credit , then the entire thing has to be completed or moved to another iteration.

csharpjava:

TDD is a technique used in an agile methodology, it is one of "Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming,

You are partially right and I don't want to nit pick with you (You shouldn't use absolutes , )

Hope you read these references :
http://www.agiledata.org/essays/tdd.html
http://www.developer.com/design/article.php/3622546

The essence of this discussion is to open our minds to possibilities (not show you as wrong or right), and maybe make us better in whatever we're doing. I hope the purpose is being served.

Ghenghis:

An iteration usually has a recommended time frame (few weeks), what you do within iteration is a function of your teams size and run rate. You deliver complete use cases within iterations (Something the customer can test end to end). So debiting a customer is not one use case while crediting the recipient another.

You have avoided the word user stories, Agile is about user stories as an when they arise which allows for putting a simple system into production quickly - A release implements a couple of stories. A fully completed system has to be in place before an online banking application is put into production for the first time, then later you can use Agile for small releases that are based on use stories, which are then integrated into the main internet banking application. Developing an Internet banking application for the first time is not a simple system, so I will recommend a waterfall methodology which will ensure that the all the functionalities needed are in place before it is put into production.

csharpjava:

You should not have started a thread titled "In Search Of "that" Software Development Methodology" which you have no clue about and you are not ready to learn. All your comments about software development here so far are techniques used in an Agile methodology. There are different Software Development Methodologies for different domains. So it is important you understand when and why you choose one methodology over the other. You cannot understand this unless you have a solid background in Software Engineering and this is the reason you have done nothing so far but disagree with me and cannot understand all my valuable contributions on this topic.

^^ It appears you're taking it quite personal, I will refrain from talking about my personal qualification, it serves no purpose here (if I do, it'll generally derail this thread), as opined:

Ghenghis:
,
The essence of this discussion is to open our minds to possibilities (not show you as wrong or right), and maybe make us better in whatever we're doing. I hope the purpose is being served.

That said, keep in mind that this thread is an extension of this thread ==> https://www.nairaland.com/nigeria/topic-878253.0.html And As I noted in the first post:

delomos:
This is an off-shoot of this post  ==> https://www.nairaland.com/nigeria/topic-878253.0.html (please read that thread and understand what is being discussed before contributing):,

Keep that on mind.

While it's nice to learn terminologies, it's more important to learn practicalities and edges, and I'd quote again (just in case it's missed the 1st time):

Ghenghis:

,
The essence of this discussion is to open our minds to possibilities (not show you as wrong or right), and maybe make us better in whatever we're doing. I hope the purpose is being served.

Now back to regular programming:

csharpjava:

, Agile is about user stories as an when they arise which allows for putting a simple system into production quickly - A release implements a couple of stories. A fully completed system has to be in place before an online banking application is put into production for the first time, , Developing an Internet banking application for the first time is not a simple system, so I will recommend a waterfall methodology which will ensure that the all the functionalities needed are in place before it is put into production.   

^^ I'm not sure if you're still talking agile here, for a bit, don't get to stuck on the name, think about the process. You are recommending waterfall because: ", will ensure that the all the functionalities needed are in place before it is put into production." That was fine for when computer resources was more expensive than human resource, reverse is the case these days not to mention HOW you can't get a system right on first production (not to mentioning unexpected requirements and all) -- but that's trivial, in the case of a banking system (client-facing), the best way to be sure you're correctly modeling the problem is to, break the problem into smaller chunks and ask the person who gave you the problem if you deed in fact understand their problem.

delomos:

While it's nice to learn terminologies, it's more important to learn practicalities and edges, and I'd quote again (just in case it's missed the 1st time):
Now back to regular programming:^^ I'm not sure if you're still talking agile here, for a bit, don't get to stuck on the name, think about the process.

If you want us to only discuss about processes here then you should change the topic of this thread to "The software development processes of an Agile Methodology", because all the processes you have mentioned on the thread are that of an Agile Methodology. An Agile Methodology is made up "Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility." Source: Agile software development.

Software Methodologies are there to help you decided the best method for developing a software application depending on the domain the software is required for.

I am Miss Betty Bill, I work with Dell Company here in the United State of America (Chicago Branch)

Sir it have come to my notice that Electronics sell very well there in West Africa, meaning that Nigeria is the place were Electronics is highly required in the Market.

i have decided to look our for God fearing and humble Nigerian, due to i am planning on establishing a Whole Sales and Retailers buying site there in Nigeria, where Nigerians can buy it cheap and easy.

These men are to represent the me there in Nigeria and each will handle each selling site there

But first, i will give each man a try by sending little quantity of the products to them and if you can sell and send the money back, then you have created a trust.

If you are interested you are to forward any required information to my mail
Full Name:
Occupation:
Age:
Sex:
to (bettybill98@yahoo.com)

csharpjava:

If you want us to only discuss about processes here then you should change the topic of this thread to "The software development processes of an Agile Methodology", because all the processes you have mentioned on the thread are that of an Agile Methodology. An Agile Methodology is made up "Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility." Source: Agile software development.

Software Methodologies are there to help you decided the best method for developing a software application depending on the domain the software is required for.

This is not meant to be biting so please don't take it as such :

Have you used any of these methods before ?
Where (no need for specifics)?
In collaboration with how many people ?

The reason I ask is because; you're so emphatic and your opinions seems to come from experience (No one can fault that), so I'm curious to know if these ideas are applicable in a particular locale or something.

csharpjava:

If you want us to only discuss about processes here then you should change the topic of this thread to "The software development processes of an Agile Methodology", because all the processes you have mentioned on the thread are that of an Agile Methodology. An Agile Methodology is made up "Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility." Source: Agile software development.

Software Methodologies are there to help you decided the best method for developing a software application depending on the domain the software is required for.

I get your point but I do fear that you didn't fully read the link you quoted otherwise, if you did, you are effectively contradicting yourself. It's good to see things in context of what is being discussed -- you might be displeased with my title, fair enough, you might not like my choice of words, fair enough, ultimately --  one needs to get the job done, in context.

agile software development is a[b] group of software development methodologies based on iterative and incremental development[/b], where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

Notice nothing super new is happening here, they're just naming "stuff". Trying reading though previously quoted links -- don't get too stuck up on names and terms.

Contrast that to your beloved Waterfall (read careful the bolded parts and you'd see why it's taking the backseat lately but of course read the full article on wiki):

http://en.wikipedia.org/wiki/Waterfall_development
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.

The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

@topic

There is always something new. a decade ago the fade was CMM now the fade is Agile. . . .

Am sure in d next 5 yrs. there will be another fade. i hear a lot about Lean development these days

We software practitioners like fades a lot.

And all these fads a a mere rehash of old ideas in new fancy names.  Iterative development has been done in IBM since the 60's

@delomos

Its true that Agile Methodology is an umbrella for other methodologies, but they must all comply with the four Agile Manifesto which is made up of four core values and 12 principles. Agile attempts to develop a system incrementally and one of the methodologies under Agile is Extreme Programming (XP). XP practices and processes are the ones that has dominated this thread so far. The reason I have being using the word Agile methodology is because all the methodologies under Agile must follow the four Agile Manifesto, which means that these methodologies are all similar to each other. Just to mention that there are some other methodologies which do come under the Agile methodology like RUP, SSADM, Soft System AD and other I have not heard of.

@Ghenghis  and delomos
I feel I should not have use an internet banking website as my example above, because in reality this can be developed incrementally to intergrate with the banks existing software system. But if a bank is starting for the first then an Iterative Waterfall Methodology is the best method to be used for developing its main banking application.

csharpjava:

@Ghenghis  and delomos
I feel I should not have use an internet banking website as my example above, because in reality this can be developed incrementally to intergrate with the banks existing software system. But if a bank is starting for the first then an Iterative Waterfall Methodology is the best method to be used for developing its main banking application.

Core banking is not developed using waterfall. Banking is a business environment, that goes through change always. SWIFT for instance are always changing standards etc. Core banking application requirements change as business cases change ( e.g. CBN says forex can only be purchased through Form A). No one know all these requirements at once.

Using the Waterfall in this age is too painful. the application would be obsolete by the time its released. Who do you know that currently uses waterfall ?

csharpjava:

@Ghenghis  and delomos
I feel I should not have use an internet banking website as my example above, because in reality this can be developed incrementally to intergrate with the banks existing software system. But if a bank is starting for the first then an Iterative Waterfall Methodology is the best method to be used for developing its main banking application.

correct. an iterative waterfall method would suffice for such complex system. Agile will be a disaster.


am sure this will soon degenerate into an agile vs waterfall war . . .


there are situations whereby it makes absolute sense to use waterfall . . yes

and there are occasions whereby u will be daft to use waterfall

candylips:

correct. an iterative waterfall method would suffice for such complex system. Agile will be a disaster.

am sure this will soon degenerate into an agile vs waterfall war . . .

there are situations whereby it makes absolute sense to use waterfall . . yes

and there are occasions whereby u will be daft to use waterfall

Thank you for joining in this discussion. XP which comes under Agile is good for small releases of an application, which makes it not suitable for a complex application like a core banking application. If an Agile methodology like XP is used for a core banking application, that will mean customers of the bank can deposit money into their account but they will have to wait another few months until the functionality to withdraw their money is released. Business critical applications like a core banking application will require a waterfall methodology which will require that all the functionalities that are needed to run a bank are complete before the application is release.

Ghenghis:

Core banking is not developed using waterfall. Banking is a business environment, that goes through change always. SWIFT for instance are always changing standards etc. Core banking application requirements change as business cases change ( e.g. CBN says forex can only be purchased through Form A). No one know all these requirements at once.

Using the Waterfall in this age is too painful. the application would be obsolete by the time its released. Who do you know that currently uses waterfall ?

^^ this gent continues to speak my mind BECAUSE these are war stories (I have mine too) not an academic debate. So can you answer that question: Who do you know that currently uses waterfall ?

candylips:

, an[b] iterative waterfall method [/b]would suffice for such complex system. Agile will be a disaster.  <== 2+4 and 4 + 2 are the same state, 2 - 4 and 4 - 2 are not the same, see how that relates to your statement?

am sure this will soon degenerate into an agile vs waterfall war . . .  <== not exactly.

csharpjava:

If an Agile methodology like XP is used for a core banking application, that will mean customers of the bank can deposit money into their account but they will have to wait another few months until the functionality to withdraw their money is released. Business critical applications like a core banking application will require a waterfall methodology which will require that all the functionalities that are needed to run a bank are complete before the application is release.

Not quite correct. An Agile release does not necessarily mean the application is ready for prime-time. It's merely a release that allows the stakeholders to view the work in progress, up until completion. That release is not meant for viewing or use by the end customers. I do not expect a software being developed using the Agile methodology to be made accessible to customers till the entire work is complete.

logica:

Not quite correct. An Agile release does not necessarily mean the application is ready for prime-time. It's merely a release that allows the stakeholders to view the work in progress, up until completion. That release is not meant for viewing or use by the end customers. I do not expect a software being developed using the Agile methodology to be made accessible to customers till the entire work is complete.

You are essentially correct, the customer might decide not to release the system until several milestones. However, every iteration should leave a releasable product.
In agile methods you balance priority with complexity, you start the risky parts first so you unearth problems early. However because you want complete release you also need to know the customer's priority. So in reality you release the most important thing needed by the customer first.

There are many reasons for this besides "viewing", you want quick wins that encourage client commitments etc.

Note : If all you needed was end to end viewing of work in progress , what's a mock up prototype ? (seem to serve the same purpose , )

A mock-up proto-type is fixed; it does not show work in progress; and a mock-up does not necessarily have to be real (meaning a lot of the functionality might be simulated). Not the case with Agile. For instance, a list of records can be implemented as an in-memory java.util.List in a mock-up (without any database connections), but in Agile you have an entity backed up by a database table. So a mock-up shows it CAN be done, but Agile viewing shows it HAS been done.

"The quick win" you mentioned is still essentially tied to work in progress because the stakeholders want to see that work is being done, and they want to know their hand earned cash investment is worthwhile.

logica:

A mock-up proto-type is fixed; it does not show work in progress; and a mock-up does not necessarily have to be real (meaning a lot of the functionality might be simulated). Not the case with Agile. For instance, a list of records can be mocked up as an in-memory java.util.List in a mock-up (without any database connections), but in Agile you have an entity backed up by a database table. So a mock-up shows it CAN be done, but Agile viewing shows it HAS been done.

"The quick win" you mentioned is still essentially tied to work in progress because the stakeholders want to see that work is being done, and they want to know their hand earned cash investment is worthwhile.

Great!!! I like the distinctions you made.

You know, a big reason why projects are considered a failure is not just delivery , but rather delivery on time when the client can cash in on benefits ,
The risk Agile methods manages is that if we get stuck in the middle , say 50% , the customer essentially has 50% he can go to market with. He hasn't lost everything (remember the customer's time and opportunity cost is invested in the project, so he's not just concerned about what he might have payed you. )
So we get stuck, he's customers are already using your app while you figure out the problem. Also notice that if prioritization was not properly done, the customer might end up with an essentially useless 50%. Also if you planned well and balanced impact and then, you might get to 5% and find you're out off your depth, The client can easily back out at this early stage or take other steps.

So in essence do the most important then complex first ,

Agile methods don't guarantee software delivery or success so much as they manage change, risk and expectations.

Yeah you have practices like pair programming etc. but this doesn't really fit the mould IMO(some methodologies practice formal code reviews). I think the point is:an extra developer "just looking" during development pays for itself rather that 3 after release or 10 searching for a bug 5 years down the line.

delomos:

^^ this gent continues to speak my mind BECAUSE these are war stories (I have mine too) not an academic debate. So can you answer that question: Who do you know that currently uses waterfall ?

my guy iterative waterfall != agile .

it is iterative building of core functionality but which distinct SLDC phases.

in agile (XP) you just start coding like an  iidiott without any up front design. relying on TDD to guide ur design. you can't do that in a complex  system like a core banking app. it will be disastrous  

although scrum folks will say they do some element of design but at the end of the day it looks like iterative waterfall to me

who currently use waterfall ? u will be surprised that most of the people who claim to be doing agile are actually doing an iterative version of waterfall.

Agile is just an lazy excuse for not writing documentation and not doing proper design. anyone who hides behind agile is just a lazy code monkey

candylips:

my guy iterative waterfall != agile .

it is iterative building of core functionality but which distinct SLDC phases.

in agile (XP) you just start coding like an  iidiott without any up front design. relying on TDD to guide ur design. you can't do that in a complex  system like a core banking app. it will be disastrous  

although scrum folks will say they do some element of design but at the end of the day it looks like iterative waterfall to me

who currently use waterfall ? u will be surprised that most of the people who claim to be doing agile are actually doing an iterative version of waterfall.

Agile is just an lazy excuse for not writing documentation and not doing proper design. anyone who hides behind agile is just a lazy code monkey

^^ Please read though the thread, don't just jump in randomly.

logica:

Not quite correct. An Agile release does not necessarily mean the application is ready for prime-time. It's merely a release that allows the stakeholders to view the work in progress, up until completion. That release is not meant for viewing or use by the end customers. I do not expect a software being developed using the Agile methodology to be made accessible to customers till the entire work is complete.

ehm. i think you are contradicting your self here.

so if i build a software under agile it should not be accessible to end users until the whole features are complete . . . that sounds like grandaddy waterfall sir

There really isn't anywhere it is explicitly written that only Waterfall delivers a product on completion. There is no contradiction here. A release is not final until there is reasonable completion. Any end users that have access before completion (even in Agile) are merely serving as testers and you should expect the application would not be made widely available to the full customer population.

I think the main confusion is the inability to distinguish between stakeholders and end-users. While an end-user is a stakeholder, the reverse is not always true.

From the Agile manifesto:

Twelve principles underlie the Agile Manifesto, including:[7]
Customer satisfaction by rapid delivery of useful software

Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)

[b]Working software is the principal measure of progress
[/b]Sustainable development, able to maintain a constant pace
Close, daily co-operation between business people and developers
Face-to-face conversation is the best form of communication (co-location)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances

Once again, customer == stakeholder is always true but customer == end-user is not always true. I'll leave it at that.

And it seems you assume Agile does not allow for design/modeling. You may be quite wrong there.

the main idea behind agile is that you DELIVER working software even if all the features are not complete.

the argument is that when d customer uses the software they can change their minds about what they want (FEEDBACK)

the idea is to shorten the FEEDBACK loop and ensure the customer stirs the efforts of the development team to what they really want

logica:

Once again, customer == stakeholder is always true but customer == end-user is not always true. I'll leave it at that.

And it seems you assume Agile does not allow for design/modeling. You may be quite wrong there.

actually agile sees the equation this way

customer == end-user + project sponsors. so customer is always and end user and some other people ,

stakeholder = end-users + development team +project sponsor +shareholders etc. stakeholders is everybody who will benefit from a good software


ok well agile discourages rigorous design/modelling which is fine for small to medium projects IMHO but absolutely essential in complex systems.

Jezuz. What is it that you don't understand here? OK I'll break it down to you.

Company XYZ sells a software package called DullSoft. XYZ has a Sales/Marketing Department and the department is headed by a seasoned seller who has spent donkey years on the field meeting clients and knows the software and client needs more than anybody else and as a matter of fact provided most of the requirements of the software.

In developing the next release of DullSoft, the team is using Agile. They release frequently and the head of the Sales/Marketing Department is a stakeholder and has access to the deploy site (a web app). This means this person is essentially a "customer" or using the term Agile knows him by, he is the Customer Representative. The software is not released till it has reached reasonable completion and that is when the end-users can have access. But the Sales/Marketing Department Head already has a few buddies in one of the end-user companies who were given access to this incomplete product. They are able to but access is restricted to just these select few who are no more than testers. Capishe?

candylips:

actually agile sees the equation this way

customer == end-user + project sponsors. so customer is always and end user and some other people ,

stakeholder = end-users + development team +project sponsor +shareholders etc. stakeholders is everybody who will benefit from a good software

I think you've been correct on all counts (i'll just chip this in) and those that might not benefit. So stakeholders are those that would be affected by the software. So a stakeholder might be the guy whose software you're replacing (What a nightmare ,  )

candylips:

ok well agile discourages rigorous design/modelling which is fine for small to medium projects IMHO but absolutely essential in complex systems. 

You'll get in trouble for this .
Agile actually encourages design however they design for change. Imagine how you'll build a house when you know u'll likely only sleep in in for a week. Why use brick and mortar, won't it be better to use a tent. Yeah we could use wood for the doors, so when we build the final house we'll reuse the doors.
(I stretched the analogy a bit   )
The point is in agile methods we recognize that change is inevitable, so if you keep that in mind for every activity , there're many things you do differently: this also includes design. This is where OO and patterns shine. (they are not exclusive to agile, but they make agile development possible)