CSC/ECE 517 Fall 2012/ch2b 2w28 dh: Difference between revisions
No edit summary |
|||
| (17 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
==Introduction to Software Engineering Fallacies and Pitfalls== | ==Introduction to Software Engineering Fallacies and Pitfalls== | ||
In the history of the software field, a lot of | In the history of the software field, a lot of pitfalls have been identified, and a lot of [http://en.wikipedia.org/wiki/List_of_fallacies fallacies] promulgated. But there’s a problem with those pitfalls and fallacies. Many of these fundamentally important pitfalls are learned by a [http://en.wikipedia.org/wiki/Software_engineer software engineer], but over the lifespan of the software field, all too many of them have been forgotten. These pitfalls and fallacies are fundamental to the software building field–forget or neglect them at your peril! Fallacies and Pitfalls revolving around software development is one of the reasons agile methodology was invented. Few of the popular fallacies and pitfalls related to the software development are described below.<ref name="video1">https://www.youtube.com/watch?v=HDj8MMFWmkQ<br></ref> | ||
==Fallacies== | ==Fallacies== | ||
===Neglecting Different Perspectives=== | |||
Engineers have a perspective that another engineer's point is incorrect because he/she cannot adequately defend his/her argument. | |||
Engineers often have a perspective about software solutions that cannot be quantified into a well formed argument. Before neglecting other's perspective, engineer should understand the possible reasons so that, ultimately, his/her position will be better communicated. Moreover, if that engineer is in a position to decide, his/her decisions should not be biased and prejudiced. | |||
===Resiliency towards New Methods=== | |||
Following same practices by refering to previous incidents. | |||
The adoption of newer designs always compete with the old strategy of ''When in Rome do as the Romans do'. Decision-makers forget to consider the external factors that influence the decisions in processes, procedures and coding practices. It is always better to scrutinize the external factors as it can help in outcasting the old traditional reasons which are obsoleted and no longer apply. The theory of five whys in making a decision about a practice always help in determining the faith of old methods. | |||
===Resource Estimation Factor=== | |||
Building credibility in a project design by estimating the resources already used. | |||
[http://en.wikipedia.org/wiki/Software_engineering Software engineering] is hard. In the starting, it is tough to know all the requirements. But with the time, if there is a new solution which questions the traditional approach and asks to change the direction, there should not be a second thought about it. As soon as the problem is realized, seize it, [http://en.wikipedia.org/wiki/Refactoring refactor] it. If that process is continued any longer, there will be more resources invested in that poor design. It will increase the deadline and the budget. The [http://en.wikipedia.org/wiki/Stakeholder stakeholders] will be more happy, if you do so. | |||
===Two Solutions Problem Space=== | |||
Restricting the solution domain to a problem to only two. | |||
Any solution statement always consider only the two sides of the coins and hence fail to consider the possibility of a dicey problem. This perspective may be true in few scenarios but rarely an undiagnosed problem space contain only two solutions. | |||
===Cause and Effect=== | |||
False assumption about correlation of the one cause to another. | |||
In problems such as [http://en.wikipedia.org/wiki/Troubleshooting troubleshooting] production issues, log of data is examined and if the analyzer is careless, he/she tries to [http://en.wikipedia.org/wiki/Pattern_recognition recognize pattern]. This can lead to false assumption of cause and effect relationship. | |||
This problem can ignore potential solution paths and can result in longer delays in solving problem. It is better to build a skepticism about causal relationship but not an assumption. | |||
==Pitfalls== | ==Pitfalls== | ||
| Line 50: | Line 45: | ||
Trying to predict what code you need before need it | Trying to predict what code you need before need it | ||
Programmers sometimes love to predict what customer wants and go ahead and put those features in the code. But when programmers show the feature to the customer, they disapprove it. | Programmers sometimes love to predict what customer wants and go ahead and put those features in the code. But when programmers show the feature to the customer, they disapprove it. | ||
Hence there is a need to write the [http://en.wikipedia.org/wiki/Software_testing tests] first, sync with the customer and then implement it. Programmers can use | Hence there is a need to write the [http://en.wikipedia.org/wiki/Software_testing tests] first, sync with the customer and then implement it. Programmers can use Behavior-Driven-Design<ref name="BDD">http://en.wikipedia.org/wiki/Behavior-driven_development<br></ref> (abbreviated '''BDD''') to write tests before code they need, then write code to pass the tests. In this case there is no need to predict and no wastage of development time and resources. | ||
===Negative Expectations=== | ===Negative Expectations=== | ||
| Line 60: | Line 55: | ||
===Why Do Softwares Fail=== | ===Why Do Softwares Fail=== | ||
There is a sad line about [http://en.wikipedia.org/wiki/Software software] before the [http://en.wikipedia.org/wiki/Agile_methodology agile methodology] came into software development field that ‘If we built all the building like we build software, the first [http://en.wikipedia.org/wiki/Woodpecker woodpecker] would destroy civilization.’ So what was the reason behind this saying? Following are the problems with the method of software development before agile and BDD: | There is a sad line about [http://en.wikipedia.org/wiki/Software software] before the [http://en.wikipedia.org/wiki/Agile_methodology agile methodology] came into software development field that ‘If we built all the building like we build software, the first [http://en.wikipedia.org/wiki/Woodpecker woodpecker] would destroy civilization.’ So what was the reason behind this saying? Following are the problems with the method of software development before agile and BDD:<ref name="video2">https://www.youtube.com/watch?v=q_A5kAMygOI<br></ref> | ||
===Softwares don’t do what Customers want=== | ===Softwares don’t do what Customers want=== | ||
| Line 88: | Line 83: | ||
A specialized version of Test-driven development which focuses on the behavior of the application being developed is the core of Behavior Driven Development, in which software developers must define a test set for each software unit, make sure the tests fail before implementation of the unit, implement the unit and verify that tests succeed once the unit has been implemented. | A specialized version of Test-driven development which focuses on the behavior of the application being developed is the core of Behavior Driven Development, in which software developers must define a test set for each software unit, make sure the tests fail before implementation of the unit, implement the unit and verify that tests succeed once the unit has been implemented. | ||
BDD asks questions about the behavior of the application being developed before and during development to reduce miscommunication. In this process the requirements are written down as user stories in the form of “3x5” cards, and all the stakeholders can mention their requirements without hesitation. These user stories are used to create [http://en.wikipedia.org/wiki/Acceptance_testing acceptance tests] before the actual code is written. | BDD asks questions about the behavior of the application being developed before and during development to reduce miscommunication. In this process the requirements are written down as user stories in the form of “3x5” cards, and all the stakeholders can mention their requirements without hesitation. These user stories are used to create [http://en.wikipedia.org/wiki/Acceptance_testing acceptance tests] before the actual code is written.<ref name="video2" /> | ||
[[File:BDD_life_cycle.jpg|thumb|right| | [[File:BDD_life_cycle.jpg|thumb|right|Behavior-Driven Development Life Cycle<ref name="fig">http://msdn.microsoft.com/en-us/magazine/gg490346.aspx<br></ref>]] | ||
===Pros of using BDD=== | ===Pros of using BDD=== | ||
| Line 110: | Line 105: | ||
* User stories can be formulated as acceptance tests before code is written | * User stories can be formulated as acceptance tests before code is written | ||
The user stories written by various stakeholders can be directly used to formulate acceptance test cases. So developers have acceptance test cases available even before the code development starts. This can be achieved through the tools such as [http://en.wikipedia.org/wiki/Cucumber_%28software%29 cucumber] in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails development] [en.wikipedia.org/wiki/Software_framework framework] which takes user stories as input to create acceptance test cases. | The user stories written by various stakeholders can be directly used to formulate acceptance test cases. So developers have acceptance test cases available even before the code development starts. This can be achieved through the tools such as [http://en.wikipedia.org/wiki/Cucumber_%28software%29 cucumber] in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails development] [http://en.wikipedia.org/wiki/Software_framework framework] which takes user stories as input to create acceptance test cases. | ||
* Easy to change requirements during development process | * Easy to change requirements during development process | ||
| Line 128: | Line 123: | ||
* Leads to bad software architecture | * Leads to bad software architecture | ||
Customer driven software development can sometimes lead to bad software architecture because of continuously evolving customer requirements which then reflects in the software architecture. Software which lacks good architecture makes it hard for developers to maintain the software and add new features to the existing version. | Customer driven software development can sometimes lead to bad [http://en.wikipedia.org/wiki/Software_architecture software architecture] because of continuously evolving customer requirements which then reflects in the software architecture. Software which lacks good architecture makes it hard for developers to maintain the software and add new features to the existing [http://en.wikipedia.org/wiki/Versioning version]. | ||
===“Debugging Sucks, Testing Rocks”=== | ===“Debugging Sucks, Testing Rocks”=== | ||
| Line 134: | Line 129: | ||
This is a philosophy which suggests that tests for softwares should be written in advance so that the developer does not spend all his time debugging various issues in the software. According to this philosophy it is better to invest more time into testing than into debugging, as this approach in turn considerably reduces the time spent on debugging issues. | This is a philosophy which suggests that tests for softwares should be written in advance so that the developer does not spend all his time debugging various issues in the software. According to this philosophy it is better to invest more time into testing than into debugging, as this approach in turn considerably reduces the time spent on debugging issues. | ||
[[File:DS_TR.jpg|thumb|right| | [[File:DS_TR.jpg|thumb|right|Debugging Sucks, Testing Rocks<ref name="video1" />]] | ||
===How Rails tools make it easier to follow BDD=== | ===How Rails tools make it easier to follow BDD=== | ||
BDD can be made easier using various tools in the Ruby on Rails web development framework. One such tool which supports BDD is Cucumber. Cucumber tests the software for customer understandable user stories. Cucumber can be used to ensure that customer accepts the final product and various interfaces between modules communicate efficiently. So in general Cucumber meets halfway between customer and developer. | BDD can be made easier using various tools in the Ruby on Rails [http://en.wikipedia.org/wiki/Web_application_framework web development framework]. One such tool which supports BDD is Cucumber. Cucumber tests the software for customer understandable user stories. Cucumber can be used to ensure that customer accepts the final product and various [http://en.wikipedia.org/wiki/Interfaces_%28computer_science%29 interfaces] between [http://en.wikipedia.org/wiki/Module_%28programming%29 modules] communicate efficiently. So in general Cucumber meets halfway between customer and developer. | ||
'''Example''' | '''Example''' | ||
The following example shows how Cucumber can be used in BDD: | The following example shows how Cucumber can be used in BDD:<ref name="cucumber"> http://cukes.info/ </ref> | ||
1. Describe behaviour in plain text: | 1. Describe behaviour in plain text: | ||
| Line 157: | Line 152: | ||
'''Then''' the result should be 120 on the screen | '''Then''' the result should be 120 on the screen | ||
2. Write a step definition in Ruby | 2. Write a step definition in [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] | ||
'''Given /I''' have entered ('''.*''') into the calculator'''/ do''' |n| | '''Given /I''' have entered ('''.*''') into the calculator'''/ do''' |n| | ||
| Line 177: | Line 172: | ||
==References== | ==References== | ||
<references /> | |||
==Further Reading== | ==Further Reading== | ||
#[http://behaviour-driven.org/ Behaviour Driven Design] | |||
#[http://www.ibm.com/developerworks/java/library/j-eaed2/index.html/ Test Driven Development] | |||
#[http://blogs.collab.net/agile/2007/06/21/user-story-examples-and-counterexamples/ User Stories Examples] | |||
Latest revision as of 18:06, 19 November 2012
SaaS - 4.8 - 4.9 - Fallacies & pitfalls, BDD pros & cons
Introduction to Software Engineering Fallacies and Pitfalls
In the history of the software field, a lot of pitfalls have been identified, and a lot of fallacies promulgated. But there’s a problem with those pitfalls and fallacies. Many of these fundamentally important pitfalls are learned by a software engineer, but over the lifespan of the software field, all too many of them have been forgotten. These pitfalls and fallacies are fundamental to the software building field–forget or neglect them at your peril! Fallacies and Pitfalls revolving around software development is one of the reasons agile methodology was invented. Few of the popular fallacies and pitfalls related to the software development are described below.<ref name="video1">https://www.youtube.com/watch?v=HDj8MMFWmkQ
</ref>
Fallacies
Neglecting Different Perspectives
Engineers have a perspective that another engineer's point is incorrect because he/she cannot adequately defend his/her argument. Engineers often have a perspective about software solutions that cannot be quantified into a well formed argument. Before neglecting other's perspective, engineer should understand the possible reasons so that, ultimately, his/her position will be better communicated. Moreover, if that engineer is in a position to decide, his/her decisions should not be biased and prejudiced.
Resiliency towards New Methods
Following same practices by refering to previous incidents. The adoption of newer designs always compete with the old strategy of When in Rome do as the Romans do'. Decision-makers forget to consider the external factors that influence the decisions in processes, procedures and coding practices. It is always better to scrutinize the external factors as it can help in outcasting the old traditional reasons which are obsoleted and no longer apply. The theory of five whys in making a decision about a practice always help in determining the faith of old methods.
Resource Estimation Factor
Building credibility in a project design by estimating the resources already used. Software engineering is hard. In the starting, it is tough to know all the requirements. But with the time, if there is a new solution which questions the traditional approach and asks to change the direction, there should not be a second thought about it. As soon as the problem is realized, seize it, refactor it. If that process is continued any longer, there will be more resources invested in that poor design. It will increase the deadline and the budget. The stakeholders will be more happy, if you do so.
Two Solutions Problem Space
Restricting the solution domain to a problem to only two. Any solution statement always consider only the two sides of the coins and hence fail to consider the possibility of a dicey problem. This perspective may be true in few scenarios but rarely an undiagnosed problem space contain only two solutions.
Cause and Effect
False assumption about correlation of the one cause to another. In problems such as troubleshooting production issues, log of data is examined and if the analyzer is careless, he/she tries to recognize pattern. This can lead to false assumption of cause and effect relationship. This problem can ignore potential solution paths and can result in longer delays in solving problem. It is better to build a skepticism about causal relationship but not an assumption.
Pitfalls
Temptation to Add Cool Features
Adding cool features that do not make the product more successful. Programmers are usually tempted to add cool features that customers don’t like. It is called pitfall because it happens even when programmer knows it. Programmer knows it will be rejected but he/she does it anyways and thinks that the customer will like it. But the customers hate it and it gets rejected. The philosophy is to use a method such as user stories to help prioritize the tasks that are needed to be done first. Then if there is time for cool features, they can be added. It helps in reducing wasted effort on the features that are not at all required by the customers.
Predicting Code
Trying to predict what code you need before need it
Programmers sometimes love to predict what customer wants and go ahead and put those features in the code. But when programmers show the feature to the customer, they disapprove it.
Hence there is a need to write the tests first, sync with the customer and then implement it. Programmers can use Behavior-Driven-Design<ref name="BDD">http://en.wikipedia.org/wiki/Behavior-driven_development
</ref> (abbreviated BDD) to write tests before code they need, then write code to pass the tests. In this case there is no need to predict and no wastage of development time and resources.
Negative Expectations
Careless use of negative expectations While writing tests first, the more detailed thing is when programmers say what is not supposed to happen. But the downside is there are millions of things that are not supposed to happen, so it’s pretty easy to pass the things that are not happening. But one probably do not want to do that. Many, many outputs are incorrect. The programmers should be beware of overusing “Then I should not see...”. They cannot tell if output is what they want, by saying only that it is not what they want. Hence it is better to include positives to check results such as “Then I should see...”. It will clearly state what is expected by the program.
Why Do Softwares Fail
There is a sad line about software before the agile methodology came into software development field that ‘If we built all the building like we build software, the first woodpecker would destroy civilization.’ So what was the reason behind this saying? Following are the problems with the method of software development before agile and BDD:<ref name="video2">https://www.youtube.com/watch?v=q_A5kAMygOI
</ref>
Softwares don’t do what Customers want
After a software is built and presented to the customer, they realize that “That’s not what they want, even though it sounded like it.”
Projects are Late
The problem while making a software project is the estimation of the time to build it. It is very common for the software engineering projects to run out of time. Hence they are delivered late than the date estimated.
Over Budget
Another common problem with the software development project is the estimation of the budget. Most of the projects run out of money before they are completed.
Hard to Maintain and Evolve
People expect software today to be maintainable or evolve whenever necessary. Sometimes the software project is built perfectly fine for the first time and works as intended. But software maintainenance and evolution is really hard.
This inspired the Agile Manifesto. The solution that Agile methodology provides is to work closely and continuously with the customer, not like sign a contract and come back in two years and show them the results. Not only the customer but all the stakeholders, the end users of the system, developers, people maintaining the code should be involved, so that all are on the same page. Behavior-Driven Design is the design method that gives an idea to capture the behavior that is required as opposed to how it is implemented.
Behaviour-Driven Design (BDD)
Introduction
Behavior-driven design (BDD) is a software development process which combines the principles of test-driven development and object-oriented analysis and design to provide business analysts and software developers with a process to develop quality software.
A specialized version of Test-driven development which focuses on the behavior of the application being developed is the core of Behavior Driven Development, in which software developers must define a test set for each software unit, make sure the tests fail before implementation of the unit, implement the unit and verify that tests succeed once the unit has been implemented.
BDD asks questions about the behavior of the application being developed before and during development to reduce miscommunication. In this process the requirements are written down as user stories in the form of “3x5” cards, and all the stakeholders can mention their requirements without hesitation. These user stories are used to create acceptance tests before the actual code is written.<ref name="video2" />
</ref>
Pros of using BDD
The following are some of the advantages of using Behavior-Driven Design:
- Makes it Easy to Work with Customers.
BDD uses user stories which are non-technical and allows all stakeholders to easily understand and state the requirements. Storyboards and UI sketches are used in BDD to allow all stakeholders including nontechnical to contribute towards requirements specification. Using “3x5” user story cards customers can state their requirements more effectively and without the trouble of using technical jargon.
- Enables customer to drive the end product development
Customers are continuously involved in the development of the software so that they can drive (and effectively change) the behavior of the end product during the course of the development.
- Tests are written before debugging
BDD helps software developers to come up with tests before debugging issues with the software and even before writing the code. This allows the developers to follow the Test-driven software development methodology.
- User stories can be formulated as acceptance tests before code is written
The user stories written by various stakeholders can be directly used to formulate acceptance test cases. So developers have acceptance test cases available even before the code development starts. This can be achieved through the tools such as cucumber in the Rails development framework which takes user stories as input to create acceptance test cases.
- Easy to change requirements during development process
The customer requirements and expectations may evolve and change during the course of software development. BDD has the capability to incorporate new insights from customers during development. This mainly makes use of “3x5” index cards. Since the requirements written on these cards are short it is easy to change them during development.
- Customer can keep track of the progress in development through iterations
Software developers get to meet with respective stakeholders once a week and show them how various iterations of the product being developed work.
Cons of using BDD
- Customer may not be interested to make continuous contact with developers.
Behavior-driven software development may not be very effective if the customer refuses to make continuous contact with the developer and review the various iterations. The success of BDD depends on continuous interaction with customer so as to shape the end product as per their expectations, therefore it can be disadvantageous to the project if the customer is reluctant to make continuous interactions during product development.
- Leads to bad software architecture
Customer driven software development can sometimes lead to bad software architecture because of continuously evolving customer requirements which then reflects in the software architecture. Software which lacks good architecture makes it hard for developers to maintain the software and add new features to the existing version.
“Debugging Sucks, Testing Rocks”
This is a philosophy which suggests that tests for softwares should be written in advance so that the developer does not spend all his time debugging various issues in the software. According to this philosophy it is better to invest more time into testing than into debugging, as this approach in turn considerably reduces the time spent on debugging issues.
How Rails tools make it easier to follow BDD
BDD can be made easier using various tools in the Ruby on Rails web development framework. One such tool which supports BDD is Cucumber. Cucumber tests the software for customer understandable user stories. Cucumber can be used to ensure that customer accepts the final product and various interfaces between modules communicate efficiently. So in general Cucumber meets halfway between customer and developer.
Example
The following example shows how Cucumber can be used in BDD:<ref name="cucumber"> http://cukes.info/ </ref>
1. Describe behaviour in plain text:
Feature: Addition
In order to avoid silly mistakes
As an amateur in math
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
2. Write a step definition in Ruby
Given /I have entered (.*) into the calculator/ do |n| calculator = Calculator.new calculator.push(n.to_i) end
3. Run and watch the test fail. The failed test will appear as red in Cucumber.
4. Write code to make the step pass.
5. Run and see the step pass. Once a step passes it is displayed in green.
6. Repeat steps 2 to 5 until all tests become green.
How is BDD and TDD helpful in industry
BDD and TDD are widely used in the industry for customer driven software development following the agile software development methodology. Many recently graduated professionals in the industry agree that BDD and TDD are greatly helpful in developing quality software in a short period of time.
References
<references />