Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch6 6e ch

2011-11-17T03:46:27Z

Choode:

==Agile Methodology==
Agile methodology is a repetitive and incremental process of managing projects where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams and is majorly used in [http://en.wikipedia.org/wiki/Software_development software development]. Implementing this methodology benefits the team by having them respond dynamically to the unpredictability of building software through incremental and iterative work called [http://en.wikipedia.org/wiki/Sprint_%28software_development%29 sprints]. These sprints provide project managers with several opportunities to evaluate and change the project accordingly during its life cycle as well as keeping the customer informed and involved in development process.

==History of Agile==
[http://en.wikipedia.org/wiki/Winston_W._Royce Dr. Winston Royce] presented a paper in 1970 entitled [http://blog.budzier.com/2009/04/23/managing-the-development-of-large-software-systems-royce-1970/ “Managing the Development of Large Software Systems”] which provided an outline on sequential development. In essence, his presentation described that any project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that a new phase can begin only when the previous phase has been completed. Therefore the software developers first gather the complete requirements for the project and then complete the design process, then write all of the code, and so on. There is little or no communication between the specialized groups that complete each phase of work.
In the late 1970's and throughout the 1980's, phased program planning started being used by several Japanese companies for new product development. This method took the waterfall method and overlapped the phases which meant each phase would begin, in order, but continue to be revisited throughout the project until the project reached the final phase where they would be finished in sequence in a short space of time. This led to just-in-time manufacturing and eventually agile software development.
The term "agile software development" emerged from a gathering of industry thought-leaders in Snowbird, UT in 2001. The term was first used in this manner and published in the now [http://en.wikipedia.org/wiki/Agile_software_development#Agile_Manifesto Agile Manifesto].

==Why Agile==
The Agile development methodology provides many opportunities for developers and project managers to revisit the direction of a project throughout its [http://en.wikipedia.org/wiki/Software_development_process development lifecycle]. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must be able to present a considerable increment in work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] the development teams only have one chance to get each aspect of a project right which can be a potential disadvantage. In an agile methodology, every aspect of development starting from requirements, design to testing is continually revisited throughout the lifecycle making changes as and when necessary. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction. Because this data is based on historically accurate information, much more predictable and realistic project projections can be made available for improving business decision making.

Using the Agile methodology the teams can start working on the requirement as and when they are available. It does not force them to wait until the customer had given them the final draft of the requirements. And since the teams work cycle is two weeks it gives the customer a lot of opportunities to calibrate releases for success in the real world. It can also be said that the agile methodologies help companies build the right product just like how the customers want it to be. Instead of having to commit to a piece of software which has not been written yet, the development team can now be sure writing a software that caters to the exact needs of the customer and in turn developing and delivering a competitive product to the market. At its core, agile development practices focus on the rapid delivery of business value in the form of working, tested software.

== Are agile methodologies a fad? ==
Agile has been certainly a trend word these days. In fact, every project’s development process has been influenced and evaluated to see if it can adapt to agile development process. Much of it success owes to the fact that it is more adaptive and thrive on change, even to the point of changing themselves. Given the precarious nature of the markets, business requirements are changing constantly and agile is very effective in this context. This model strives to add as much as business value to the product. With this as key driving principle, it led to the success of many projects. This is why Agile word not is a [http://en.wikipedia.org/wiki/Fad fad].

Further, If we look at underlying elements of Agile process; Collaboration, [http://en.wikipedia.org/wiki/Lean_software_development Lean development], Iterate, Visualize are smart practices. Though the credit goes to Agile process for incorporating them otherwise they are common practices, knowingly or unknowingly we have been using them from considerable time. All these practices emphasize the fact that customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership.

Does this mean above practices can be applied independently and still achieve same result? Yes, In fact, the methods foster the notion of “Inspect & Adapt” as a core principle. However, you also need to be mindful of the experience of the team and the relational nature of the practices. Many agile coaches recommend that new agile teams adopt all of [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] or all of [http://en.wikipedia.org/wiki/Extreme_programming XP]’s practices and learn them well before they try composing practices on their own.

However, It is observed that many teams that are not fully acquainted with Agile methodology, happened to be many, have fundamentally diluted agile practices by pulling them apart and consider individual practices as options. For instance, many teams do not consider having a daily stand-up, a backlog, a time-boxed iteration and an iteration review to be an effective agile implementation. They don’t even consider self-directed and x-functional teams, pairing, full transparency, customer inclusion, quality practices, teamwork & collaboration, and retrospectives as important or necessary. They iterate for a short while and then fail. Immediately they blame it on “Agile,” implying that the approach doesn’t work. While nothing could be further from the truth, they simply don’t understand that. The point is agility is not simply a set of practices that can be individually applied. Instead, it’s a holistic set of related practices that work together to reinforce the core tenets of agile teams.

Agile methodologies are certainly not a fad they have been and are still continuing to be one of the best development paradigms. The Agile manifesto just celebrated its tenth anniversary. Scrum was first used and shared in 1993. XP was formed in 1999. [http://en.wikipedia.org/wiki/Lean_software_development#Lean_principles Lean principles] were established well before those time-frames. So the practices, while potentially being practiced with youthful enthusiasm, are not temporary. They’ve also crossed over into the mainstream. And they are certainly not a craze. For example, the esteemed [http://en.wikipedia.org/wiki/Project_Management_Institute PMI] is now introducing an agile certification. So, they’d are not mere fad anymore.

== Has their effectiveness really outstripped earlier "heavier weight" methodologies? ==

Apparently, on the surface, it appears that agile is the only way that promises success for the projects. However, the success of agile depends on many factors and, as long as these are valid the agile methodology can be adopted. In fact, one of the key criteria is constant engagement of customer in the process. If that does not happen then agile methodology is bound to fail and traditional methods are the alternative. Clearly, we can see that agile methodologies have some limitations. In the rest of this section we go through the key criteria's that are necessary and for a project to adopt Agile methodology and therefore Heavy weight methodologies excel. We finally show some of the statistics on the effectiveness of both the methodologies.

First of all, Agile methodologies are so fundamentally people-oriented, it's essential that team should be enthusiastic and capable enough to work in an intense environment, and continuously engaging with customers. However, if the team is reluctant then imposing agile methodology severely impacts the process. Further, it's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that, customers who are unaware this process when approached really understand the benefits of it and start engaging in the process.

However, Agile methods can't be used on large projects. The problem with agile is it has very significant potential for rework based on the increased likelihood for poor design decisions being made early in the development, when the breadth and depth of the solution is not well understood. It is believed that this risk is mitigated by adopting sound, thorough planning techniques that expose the breadth and depth to the team up front, allowing them to make intelligent decisions regarding the sprints and intelligent decisions about design that reduce the risk of rework. The agile concepts have much to commend them - as articulated in the post - but seem to lack (to me, at least), the necessary preliminary rigor in planning to reduce the potential risk. So, it is observed that Agile excels only if the projects are small and medium sized.

Finally, it’s primarily comes down to the people and customers. If the people and customers involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular, one should never try to impose agile working on a team that doesn't want to try it. And for most project, agile methods have really helped them in achieving success. The following survey results summarize the same.

[[File:Success Rate.jpg|Success Rate.jpg]][[File:Effectiveness.jpg|500px]]

Survey results conducted by [http://www.ambysoft.com/surveys/success2011.html Ambysoft] clearly show that success rate of Agile is high compared to traditional heavy weight methods.

== Agile success stories ==
In this section, we will go over some of the major success stories of projects adopting Agile methodology and finally summarize the overall success rate of the agile process.

=== Betaport ===
[http://en.wikipedia.org/wiki/Beatport Beatport] is a product similar to [http://en.wikipedia.org/wiki/ITunes iTunes] but catered to DJ’s very popular music DJ mixing software. It was a developed by geographically distributor team spreading across India and customers in Davin, Berlin and London. They adopted Agile process and it took them 20 months, divided in four stages. It involved keeping a small release cycle, hiring an agile experienced product owner, involving all the stakeholders and stay focusing on enterprise architecture to ensure they are always aligned with company goals.

[[File:success rate - Agile.jpg|right|thumb|400px]]
=== BMC Software ===
[http://en.wikipedia.org/wiki/BMC_Software BMC Software] team followed few principles as part of adopting their teams to Agile process. After that, BMC Productivity Index improved to 27 from what was an average of 6 to 16 in other software types. The principles included.

• Leadership and social contract with the team.

• Know-how - used Rally with a 50/50 spend on professional services and coaching while the other 50% was used for Rally’s application – this combination was critical to go as fast as we did.

• Flexibility - have to take the adoption incrementally and iteratively.

• Patience - cannot Agile the Agile – as it is changing the software, the process and the organizational structure.

=== Pearson eCollege online learning software ===
[http://en.wikipedia.org/wiki/ECollege Pearson eCollege] online learning software started working on Scrum for the last two years with teams in Denver and Sri Lanka. Initially, they were following waterfall model with huge business requirement document and they slowly started moving to Agile and within four releases they were able deliver quality builds from that day. They used continuous integration server and because of which bugs got reduced drastically as they were notified in early stages of development. They had only one release for staging and production.

It then dramatically increased the speed of the team and clear visibility has allowed them to react at each two week iteration with strict prioritization. As a result, they were not delivering the wrong or unwanted features.

In general, surveys reveal that about 55 percent of the projects which adopted Agile have been successful.

== References ==
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] 
[http://www.agile-methodology.com/ Agile Methodology Website] 
[http://www.ambysoft.com/surveys/success2011.html 2011 IT Project Success Rates Survey Results] 
[http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile Deciding What Kind of Projects are Most Suited for Agile] 
[http://martinfowler.com/articles/newMethodology.html The New Methodology] 

== Further Reading ==
[http://agilemethodology.org/ Agile Methodology] 
[http://digitalcommons.pace.edu/dissertations/AAI3271868/ An investigation into the effectiveness of agile software development with a highly distributed workforce] at DigitalCommons@Pace 
[http://www.rallydev.com/agileblog/2009/03/5-stories-of-agile-success/ 5 Stories of Agile Success] at AGILEBLOG

CSC/ECE 517 Fall 2011/ch6 6e ch

2011-11-17T03:23:08Z

Choode: Created page with "==Agile Methodology== Agile methodology is a repetitive and incremental process of managing projects where requirements and solutions evolve through collaboration between self-or..."

==Agile Methodology==
Agile methodology is a repetitive and incremental process of managing projects where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams and is majorly used in [http://en.wikipedia.org/wiki/Software_development software development]. Implementing this methodology benefits the team by having them respond dynamically to the unpredictability of building software through incremental and iterative work called [http://en.wikipedia.org/wiki/Sprint_%28software_development%29 sprints]. These sprints provide project managers with several opportunities to evaluate and change the project accordingly during its life cycle as well as keeping the customer informed and involved in development process.

==History of Agile==
[http://en.wikipedia.org/wiki/Winston_W._Royce Dr. Winston Royce] presented a paper in 1970 entitled [http://blog.budzier.com/2009/04/23/managing-the-development-of-large-software-systems-royce-1970/ “Managing the Development of Large Software Systems”] which provided an outline on sequential development. In essence, his presentation described that any project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that a new phase can begin only when the previous phase has been completed. Therefore the software developers first gather the complete requirements for the project and then complete the design process, then write all of the code, and so on. There is little or no communication between the specialized groups that complete each phase of work.
In the late 1970's and throughout the 1980's, phased program planning started being used by several Japanese companies for new product development. This method took the waterfall method and overlapped the phases which meant each phase would begin, in order, but continue to be revisited throughout the project until the project reached the final phase where they would be finished in sequence in a short space of time. This led to just-in-time manufacturing and eventually agile software development.
The term "agile software development" emerged from a gathering of industry thought-leaders in Snowbird, UT in 2001. The term was first used in this manner and published in the now [http://en.wikipedia.org/wiki/Agile_software_development#Agile_Manifesto Agile Manifesto].

==Why Agile==
The Agile development methodology provides many opportunities for developers and project managers to revisit the direction of a project throughout its [http://en.wikipedia.org/wiki/Software_development_process development lifecycle]. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must be able to present a considerable increment in work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] the development teams only have one chance to get each aspect of a project right which can be a potential disadvantage. In an agile methodology, every aspect of development starting from requirements, design to testing is continually revisited throughout the lifecycle making changes as and when necessary. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction. Because this data is based on historically accurate information, much more predictable and realistic project projections can be made available for improving business decision making.

Using the Agile methodology the teams can start working on the requirement as and when they are available. It does not force them to wait until the customer had given them the final draft of the requirements. And since the teams work cycle is two weeks it gives the customer a lot of opportunities to calibrate releases for success in the real world. It can also be said that the agile methodologies help companies build the right product just like how the customers want it to be. Instead of having to commit to a piece of software which has not been written yet, the development team can now be sure writing a software that caters to the exact needs of the customer and in turn developing and delivering a competitive product to the market. At its core, agile development practices focus on the rapid delivery of business value in the form of working, tested software.

== Are agile methodologies a fad? ==
Agile has been certainly a trend word these days. In fact, every project’s development process has been influenced and evaluated to see if it can adapt to agile development process. Much of it success owes to the fact that it is more adaptive and thrive on change, even to the point of changing themselves. Given the precarious nature of the markets, business requirements are changing constantly and agile is very effective in this context. This model strives to add as much as business value to the product. With this as key driving principle, it led to the success of many projects. This is why Agile word not is a [http://en.wikipedia.org/wiki/Fad fad].

Further, If we look at underlying elements of Agile process; Collaboration, [http://en.wikipedia.org/wiki/Lean_software_development Lean development], Iterate, Visualize are smart practices. Though the credit goes to Agile process for incorporating them otherwise they are common practices, knowingly or unknowingly we have been using them from considerable time. All these practices emphasize the fact that customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership.

Does this mean above practices can be applied independently and still achieve same result? Yes, In fact, the methods foster the notion of “Inspect & Adapt” as a core principle. However, you also need to be mindful of the experience of the team and the relational nature of the practices. Many agile coaches recommend that new agile teams adopt all of [http://en.wikipedia.org/wiki/Scrum_%28development%29 Scrum] or all of [http://en.wikipedia.org/wiki/Extreme_programming XP]’s practices and learn them well before they try composing practices on their own.

However, It is observed that many teams that are not fully acquainted with Agile methodology, happened to be many, have fundamentally diluted agile practices by pulling them apart and consider individual practices as options. For instance, many teams do not consider having a daily stand-up, a backlog, a time-boxed iteration and an iteration review to be an effective agile implementation. They don’t even consider self-directed and x-functional teams, pairing, full transparency, customer inclusion, quality practices, teamwork & collaboration, and retrospectives as important or necessary. They iterate for a short while and then fail. Immediately they blame it on “Agile,” implying that the approach doesn’t work. While nothing could be further from the truth, they simply don’t understand that. The point is agility is not simply a set of practices that can be individually applied. Instead, it’s a holistic set of related practices that work together to reinforce the core tenets of agile teams.

Agile methodologies are certainly not a fad they have been and are still continuing to be one of the best development paradigms. The Agile manifesto just celebrated its tenth anniversary. Scrum was first used and shared in 1993. XP was formed in 1999. [http://en.wikipedia.org/wiki/Lean_software_development#Lean_principles Lean principles] were established well before those time-frames. So the practices, while potentially being practiced with youthful enthusiasm, are not temporary. They’ve also crossed over into the mainstream. And they are certainly not a craze. For example, the esteemed [http://en.wikipedia.org/wiki/Project_Management_Institute PMI] is now introducing an agile certification. So, they’d are not mere fad anymore.

== Has their effectiveness really outstripped earlier "heavier weight" methodologies? ==

Apparently, on the surface, it appears that agile is the only way that promises success for the projects. However, the success of agile depends on many factors and, as long as these are valid the agile methodology can be adopted. In fact, one of the key criteria is constant engagement of customer in the process. If that does not happen then agile methodology is bound to fail and traditional methods are the alternative. Clearly, we can see that agile methodologies have some limitations. In the rest of this section we go through the key criteria's that are necessary and for a project to adopt Agile methodology and therefore Heavy weight methodologies excel. We finally show some of the statistics on the effectiveness of both the methodologies.

First of all, Agile methodologies are so fundamentally people-oriented, it's essential that team should be enthusiastic and capable enough to work in an intense environment, and continuously engaging with customers. However, if the team is reluctant then imposing agile methodology severely impacts the process. Further, it's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that, customers who are unaware this process when approached really understand the benefits of it and start engaging in the process.

However, Agile methods can't be used on large projects. The problem with agile is it has very significant potential for rework based on the increased likelihood for poor design decisions being made early in the development, when the breadth and depth of the solution is not well understood. It is believed that this risk is mitigated by adopting sound, thorough planning techniques that expose the breadth and depth to the team up front, allowing them to make intelligent decisions regarding the sprints and intelligent decisions about design that reduce the risk of rework. The agile concepts have much to commend them - as articulated in the post - but seem to lack (to me, at least), the necessary preliminary rigor in planning to reduce the potential risk. So, it is observed that Agile excels only if the projects are small and medium sized.

Finally, it’s primarily comes down to the people and customers. If the people and customers involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular, one should never try to impose agile working on a team that doesn't want to try it. And for most project, agile methods have really helped them in achieving success. The following survey results summarize the same.

[[File:Success Rate.jpg|Success Rate.jpg]][[File:Effectiveness.jpg|500px]]

Survey results conducted by [http://www.ambysoft.com/surveys/success2011.html Ambysoft] clearly show that success rate of Agile is high compared to traditional heavy weight methods.

== Agile success stories ==
In this section, we will go over some of the major success stories of projects adopting Agile methodology and finally summarize the overall success rate of the agile process.

[[File:success rate - Agile.jpg|right|thumb|500px]]
=== Betaport ===
[http://en.wikipedia.org/wiki/Beatport Beatport] is a product similar to [http://en.wikipedia.org/wiki/ITunes iTunes] but catered to DJ’s very popular music DJ mixing software. It was a developed by geographically distributor team spreading across India and customers in Davin, Berlin and London. They adopted Agile process and it took them 20 months, divided in four stages. It involved keeping a small release cycle, hiring an agile experienced product owner, involving all the stakeholders and stay focusing on enterprise architecture to ensure they are always aligned with company goals.

=== BMC Software ===
[http://en.wikipedia.org/wiki/BMC_Software BMC Software] team followed few principles as part of adopting their teams to Agile process. After that, BMC Productivity Index improved to 27 from what was an average of 6 to 16 in other software types. The principles included.

• Leadership and social contract with the team.

• Know-how - used Rally with a 50/50 spend on professional services and coaching while the other 50% was used for Rally’s application – this combination was critical to go as fast as we did.

• Flexibility - have to take the adoption incrementally and iteratively.

• Patience - cannot Agile the Agile – as it is changing the software, the process and the organizational structure.

=== Pearson eCollege online learning software ===
[http://en.wikipedia.org/wiki/ECollege Pearson eCollege] online learning software started working on Scrum for the last two years with teams in Denver and Sri Lanka. Initially, they were following waterfall model with huge business requirement document and they slowly started moving to Agile and within four releases they were able deliver quality builds from that day. They used continuous integration server and because of which bugs got reduced drastically as they were notified in early stages of development. They had only one release for staging and production.

It then dramatically increased the speed of the team and clear visibility has allowed them to react at each two week iteration with strict prioritization. As a result, they were not delivering the wrong or unwanted features.

In general, surveys reveal that about 55 percent of the projects which adopted Agile have been successful.

== References ==
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] 
[http://www.agile-methodology.com/ Agile Methodology Website] 
[http://www.ambysoft.com/surveys/success2011.html 2011 IT Project Success Rates Survey Results] 
[http://blog.mountaingoatsoftware.com/deciding-what-kind-of-projects-are-most-suited-for-agile Deciding What Kind of Projects are Most Suited for Agile] 
[http://martinfowler.com/articles/newMethodology.html The New Methodology] 

== Further Reading ==
[http://agilemethodology.org/ Agile Methodology] 
[http://digitalcommons.pace.edu/dissertations/AAI3271868/ An investigation into the effectiveness of agile software development with a highly distributed workforce] at DigitalCommons@Pace 
[http://www.rallydev.com/agileblog/2009/03/5-stories-of-agile-success/ 5 Stories of Agile Success] at AGILEBLOG

File:Success Rate.jpg

2011-11-17T02:39:57Z

Choode:

File:Effectiveness.jpg

2011-11-17T02:39:37Z

Choode:

File:Success rate - Agile.jpg

2011-11-17T02:39:21Z

Choode:

CSC/ECE 517 Fall 2011

2011-11-11T07:59:46Z

Choode:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f mm]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h as]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[CSC/ECE 517 Fall 2011/ch17 5b uo]]

*[[CSC/ECE 517 Fall 2011/ch17 5b br]]

*[[CSC/ECE 517 Fall 2011/ch5 5d he]]

*[[CSC/ECE 517 Fall 2011/ch5 6d ny]]

*[[CSC/ECE 517 Fall 2011/ch6 6d sk]]

*[[CSC/ECE 517 Fall 2011/ch6 6e ch]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 2a ca

2011-09-21T19:01:51Z

Choode: Created page with "Currying in mathematics is defined as the technique of breaking down a function that takes multiple [http://en.wikipedia.org/wiki/Parameter_(computer_science) parameters] into a ..."

Currying in mathematics is defined as the technique of breaking down a function that takes multiple [http://en.wikipedia.org/wiki/Parameter_(computer_science) parameters] into a sequence of functions all of which take just one parameter. Similarly currying in computer science refers to the procedure of converting a function that takes n number of [http://en.wikipedia.org/wiki/Parameter_(computer_science) arguments] into a chain of functions each of which takes a single argument. Currying was invented by [http://en.wikipedia.org/wiki/Moses_Sch%C3%B6nfinkel Moses Schönfinkel] and [http://en.wikipedia.org/wiki/Gottlob_Frege Gottlob Frege], and later rediscovered by [http://en.wikipedia.org/wiki/Haskell_Curry Haskell Curry]. The name "currying" was coined by [http://en.wikipedia.org/wiki/Christopher_Strachey Christopher Strachey] in 1967.

==Definition==

Currying is defined as the technique of converting a function with multiple arguments into a function with fewer arguments. Currying, in general is performed by passing a lower order function with a single argument as a parameter to the next higher order function.

Suppose we have a function '''''&fnof;''''' that takes in two parameters

&fnof;(a, b) = a + b

Currying can be demonstrated by passing only one parameter to this function say 2 such that we get '''''&fnof;(2 ,b)''''' which results in a new function '''''g''''' that takes in just one parameter i.e '''''g(b) = &fnof;(2, b) = 2 + b''''' . And then passing a parameter to function '''''g''''' solves our initial equation '''''g(3) = &fnof;(2, 3) = 2 + 3'''''. Notice how each of the function takes in just one argument.

By looking at the above example we can say that a curried function returns a new function when it is called with less than the expected number of arguments. And if the original function takes n number of arguments then the returned function would take n-1 number of arguments thus producing a sequence of functions as in [http://en.wikipedia.org/wiki/Lambda_calculus lambda calculus].

In the context of a given [http://en.wikipedia.org/wiki/Programming_language programming language], to say that the programming language supports currying is to mean that the [http://en.wikipedia.org/wiki/Compiler compiler] understands the concept of currying to a certain degree. That is the programming language is inherently able to take a function with multiple arguments and break it down into server smaller functions each of which take a single argument.

==Currying and Partial Application functions==

Currying and [http://en.wikipedia.org/wiki/Partial_application Partial Application] are two different approaches for transforming a given function into a new function usually with a smaller [http://en.wikipedia.org/wiki/Arity arity]. They are often confused with each other.

Consider a function '''''&fnof;''''' that takes in two arguments

&fnof;: a × b → R

Currying takes the function '''''&fnof;''''' and turns it into a new function '''''g'''''

g: a → (b → R)

Instead of calling '''''&fnof;''''' with two arguments, we invoke function '''''g''''' with the first argument. The result is a function that we then call with the second argument to produce the final result. Thus, if the uncurried function '''''&fnof;''''' is invoked as '''''&fnof;(2, 3)'''''. Then, the curried function '''''g''''' is invoked as '''''g(2)(3)'''''

Partial application on the other hand takes the same function '''''&fnof;''''' and a fixed value '''''a''''' for the first argument to produce a new function

g: b → R

'''''g''''' does the same as '''''&fnof;''''', but only has to fill in the second parameter which is why its arity is one less than the arity of function '''''&fnof;'''''.

For more clarity lets consider a function that takes three arguments.

&fnof;: a x b x c → R

Now, currying the function '''''&fnof;''''' turns it into a function '''''g'''''

g: a → (b → (c → R))

Calling '''''g''''' with just one parameter would return a function that would take one parameter and return another function.

In contrast for partial function, given the function '''''&fnof;''''' and a fixed value '''a''' for the first argument, we get a new function '''''g'''''

g(y, z) → R

In the above case calling a partial function with just one argument returns a function that takes in two arguments which is clearly different to that of currying.

Thus we can say that a curried function is a function that will return a new function when it is called with less number of arguments than it expects and applying a function to less arguments than it expects is called partial function application. So, stated even more precisely, a curried function is a function that will return a new function when it is partially applied.

==Advantages of Currying==

The primary advantage of Currying is that it allows the programmer to invoke a function with fewer arguments than expected, thereby creating a new, possibly very useful function. For example, a function add which takes two arguments and adds them could be invoked with a single argument say 5 to create a new function that takes only one argument and which always adds five to that argument.

Currying improves code readability. Consider the following [http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 Haskell] snippet.

lengths :: <nowiki>[[a]]</nowiki> -> [Int]
lengths xs = map length xs
 
lengths' :: <nowiki>[[a]]</nowiki> -> [Int]
lengths' = map length

Removing the extra variable xs makes the code easier to read and there is no need to mentally keep clear what xs is.

Currying approach also allows us to write less code, with high level of maintainability. Consider the following example in [http://en.wikipedia.org/wiki/Scheme_%28programming_language%29 Scheme].

(define (add a b)
(action + a b))
 
(define (mul a b)
(action * a b))
 
(define (action kind a b)
(kind a b))

If the user code invokes add method, it in turn calls action with kind +. The same happens with mul method. All add does is wrapping the call to action with the appropriate kind. Now, consider curried definitions of these functions:

(define add-curried
((curry action) +))
 
(define mul-curried
((curry action) *))

The functions have now become considerably shorter. We just curried the function action by passing it only one argument, the kind, and got the curried function which accepts the rest two arguments. Imagine that function action would immediately be rewritten to accept 3 more arguments. Without currying one would have to rewrite the implementations of add and mul.

(define (action kind a b c d e)
(kind a b c d e))

Curried expressions can be understood locally - their dependence on their environment is entirely through their free variables. They tend to have fewer free variables and more bound variables than comparable imperative code, since they do not rely as heavily on assignment to express the computation. An imperative program proceeds by altering some globally-accessible store of values. By contrast, a functional program proceeds by function application and the return of values. This eliminates large classes of errors associated with maintaining a global store of values.

==Applications of Currying==

Currying can be implemented in any language that supports closures(lambdas), and is useful for partial function application like in UI programming where all the input necessary for the execution of function isn’t received, so a curried function is passed around with already received inputs captured in it.

Currying is particularly useful when we need to slowly build up our function over several different iterations.

==Currying implementation in different languages==

===Currying in Declarative Languages like Functional Languages===

[http://en.wikipedia.org/wiki/Functional_programming Functional programming] languages are a class of languages designed to reflect the way people think mathematically, rather than reflect the underlying machine.

====Haskell====

Consider a method of sorting which takes two parameters, the comparison function and the list to be sorted. Pick an element '''x''', and divide the whole list into three parts. The first part has all elements that should go before '''x'''. The second part consists of all of the elements that are equal '''x'''. The third has the elements that ought to go after '''x'''. When the method ‘quickSort’ is applied to the list ‘sentence’,
it gives the output as shown below.

sentence = [ “I”, “have”, “a”, “thing”, “for”, “Linux”]
quickSort usual sentence
 
'''Output'''
[“I”, “Linux”, “a”, “for”, “have”, “thing”]

When the function is curried, we can apply only the comparison parameter. usualSort only remembers the comparison. Thus by just passing 'sentence' to usualSort, we get the required output.

usualSort = quicksort usual
usualSort sentence
 
'''Output'''
[“I”, “Linux”, “a” , “for” , “have” , “thing”]

====Scheme====

[http://en.wikipedia.org/wiki/Scheme_%28programming_language%29 Scheme] is one of the two dialects of [http://en.wikipedia.org/wiki/Lisp_%28programming_language%29 LISP](the second oldest programming language).

The following function takes another function ‘f’ as a parameter and some number of arguments to be applied to ‘f’ as arguments. It returns a function which expects more arguments

(define (currying f . args)
(lambda i
(apply fun (append args i))))

Then a function to double a value can be curried as shown

(define double (currying * 2))
(double 6)
 
'''Output'''
12

===Currying in imperative languages===

[http://en.wikipedia.org/wiki/Imperative_programming Imperative programming] is a programming paradigm that describes computation in terms of statements that change a program state.

====C#====
[http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#] is a general purpose Object Oriented Programming language. Consider the simple example of adding two numbers.

class Adding{
delegate int Operation(int x, int y);
 
static void Main(){
Operation add = delegate(int x, int y){
return x + y;
};
Console.WriteLine(add(13, 29));
}
}
 
'''Output'''
42 //13+29

Now let us re-write the same code with currying technique.

class Adding{
delegate Currying2 Currying (int x);
delegate int Currying2(int y);
 
static void Main() {
Currying add = delegate(int x)
{
return delegate(int y)
{
return x + y;
};
};
Console.WriteLine(add(13)(29));
}
}
 
'''Output'''
42

====JavaScript====

[http://en.wikipedia.org/wiki/JavaScript JavaScript] is a scripting language for client side programming of a [http://en.wikipedia.org/wiki/Web_application web based application].

Taking the same example of adding two numbers, we have the function f that takes two parameters a1 and a2 and the curried function 'currying' that takes just one parameter and both producing the same output.

function f(a1, a2) {
return a1 + a2;
}

 
function currying(a1) {
return function (a2) {
return f(a1, a2,);
};
}
 
currying(5)(10);
 
'''Output'''
15

Let’s consider a practical example for currying in JavaScript

Consider a function 'currying' which take another function ‘f’ as a parameter and also a ‘scope’ variable.
The function creates an array of arguments passed to it.

function currying (f, scope) {
var scope = scope || window;
var argArray = [];
var length = arguments.length
for (var i=2; i < length; ++i) {
argArray.push(arguments[i]);
};
 
return function() {
<code>f.apply(scope, argArray); </code>
};
}

We can use the above 'Curried' function to a click event on the webpage

var x = document.getElementById('element');
x.addEventListener('click', currying(greeting, x, 'Welcome'), false)
 
function greeting(msg) {
window.alert(msg+'\n You clicked on '+this.id);
}

Here the addEventListener waits for an external click on the ‘element’. When the button is clicked the ‘currying’ function is invoked which gathers the argument and then invokes the ‘greeting’ function

====Ruby====
[http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] is a dynamic scripting language that mainly runs on the [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework. Ruby explicitly supports currying.
Consider the example of adding two numbers. Normally the [http://www.ruby-doc.org/core/classes/Proc.html proc] looks like this
plus = lambda { |a, b| a + b }
puts plus [1, 2]
 
'''Output'''
3
Now we modify the program to fix one variable. Let us fix it to one and conveniently call it ‘incrementer’.
incrementer = lambda { |x| x+1 }
puts incrementer.call(43)
puts incrementer.call(57)
 
'''Output'''
44
58

In Ruby 1.9, you create a curry-able proc by calling the curry method on it. If you subsequently call this curried proc with fewer parameters than it expects, it will not execute. Instead, it returns a new proc with those parameters already bound.
Consider the following example written in Ruby 1.9, taken from PragDave, which curries the 'plus' proc.
curried_plus = plus.curry
# create two procs based on plus, but with the first parameter
# already set to a value
plus_two = curried_plus[2]
plus_ten = curried_plus[10]
 
puts plus_two[3]
puts plus_ten[3]
 
'''Output'''
5
13

==References==
1. [http://en.wikipedia.org/wiki/Currying Currying - Wikipedia] 
2. [http://blogs.msdn.com/b/wesdyer/archive/2007/01/29/currying-and-partial-function-application.aspx Currying and Partial Function Application]at MSDN Blogs 
3. [http://www.2ality.com/2011/09/currying-vs-part-eval.html Currying-vs-Partial function] at 2ality by Dr. Axel Rauschmayer. 
4. [http://www.amateurtopologist.com/blog/2010/02/12/why-i-love-currying/ Why I love Currying] blog at amateurtopologist.com 
5. [http://www.haskell.org/haskellwiki/Currying Currying - HaskellWiki] 
6. [http://pragdave.blogs.pragprog.com/pragdave/2008/09/fun-with-procs.html Fun with Procs in Ruby 1.9] at PragDave by Dave Thomas
==Further Reading==
Language Specific Implementations 
* [http://www.haskell.org/haskellwiki/Currying Currying] at HaskellWiki 
* [http://www.scala-lang.org/node/135 Currying] in Scala 
* [http://www.engr.uconn.edu/~jeffm/Papers/curry.html Function Currying in Scheme] 
* [http://asg.unige.ch/site/papers/Dami91a.pdf Currying in C] 
* [http://perldesignpatterns.com/?CurryingConcept Currying in Perl]