CSC/ECE 517 Fall 2012/ch2b 2w28 dh: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(10 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 facts have been identified, and a lot of [http://en.wikipedia.org/wiki/List_of_fallacies fallacies] promulgated. There’s a problem with those facts–and, as you might imagine, those fallacies. Many of these fundamentally important facts 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 facts and fallacies are fundamental to the software building field–forget or neglect them at your peril!
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==


Five Fatal Logical Fallacies of Software Development
===Neglecting Different Perspectives===


===Fallacy Fallacy===
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.


Drawing the conclusion that another engineer's point is incorrect because he cannot adequately defend his position.
===Resiliency towards New Methods===
Engineers often have an intuition about engineering solutions — an intuition that isn't always easily quantifiable into a well formed argument. Engineer should seek first to understand the possible reasons for taking an opposing position so that, ultimately, his/her designs will be better informed. Moreover, if that engineer is in a decision making position, his/her decisions will be viewed as more fair and well thought out.


===Appeal to Tradition===
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.


Justifying or defending a coding practice by citing precedent.
===Resource Estimation Factor===
It is usually an internal struggle between introducing newer, more well thought out designs vs adopting a 'When in Rome do as the Romans do' strategy to maintain consistency in the code base.
Processes, procedures and coding practices aren't developed in a vacuum. There are a dizzying array of external factors that influence these decisions. Many times, if one examines the factors that led to these decisions, he/she will find that the original reasons no longer apply or are diminished. It never hurts to apply the five whys to find out if it makes sense to continue a particular practice.


===The Sunk Cost Fallacy===
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.


Believing to continue forward with a particular design, project, etc. because too much time, money and other resources have already been poured into a solution.
===Two Solutions Problem Space===
[http://en.wikipedia.org/wiki/Software_engineering Software engineering] is hard. When a project is started,  all of the facts are not present. There should not be any fear to change direction once new information leads to question the viability of the original decisions.
Is that [http://en.wikipedia.org/wiki/Refactoring refactoring] effort that you thought would take 2 days instead proving to drag into 2 weeks with no end in sight? Don't be afraid to stop because now it is known that its more involved that it was originally thought. Cut your losses. It will make the project deadline and the [http://en.wikipedia.org/wiki/Stakeholder stakeholders] happy.


===The False Dichotomy===
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.


Constraining a problem space to two — and only two solutions.
===Cause and Effect===
Statements like the following are often made: 'The slow performance is due to either a missing database index or a changed execution plan from crossing a partition'.
While these may be likely culprits, such statements ignore an entire universe of other possibilities including [http://en.wikipedia.org/wiki/Java_virtual_machine JVM] [http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29 GC] pauses, [http://en.wikipedia.org/wiki/Network_latency#Packet-switched_networks network latencies], etc. Rarely are there only two possibilities when dealing with undiagnosed problems.


===Confusing Correlation and Causation===
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.
Assuming that because events occur together that one must cause the other.
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.
This is another fallacy that tends to be seen when [http://en.wikipedia.org/wiki/Troubleshooting troubleshooting] production issues. In such situations, reams of data are analyzed and we humans do what we're best at: [http://en.wikipedia.org/wiki/Pattern_recognition pattern recognition]. If we're not careful, this pattern recognition can lead to assume that one event causes another to occur.
Incorrectly asserting causation is dangerous in this case because it can lead down to unproductive exploratory paths and thus lead to longer diagnosis times. Knowing in advance that events are correlated but not necessarily causal can introduce a healthy dose of skepticism into the troubleshooting process.


==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 [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-Driven-Design] (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.
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|Behavior-Driven Development Life Cycle<ref name="fig">http://msdn.microsoft.com/en-us/magazine/gg490346.aspx<br></ref>]]
[[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>]]
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|alt=“Debugging Sucks, Testing Rocks”]]
[[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===

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" />

Behavior-Driven Development Life Cycle<ref name="fig">http://msdn.microsoft.com/en-us/magazine/gg490346.aspx
</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.

Debugging Sucks, Testing Rocks<ref name="video1" />

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 />

Further Reading

  1. Behaviour Driven Design
  2. Test Driven Development
  3. User Stories Examples
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2b_2w28_dh&oldid=70627"