CSC/ECE 517 Fall 2012/ch2b 2w28 dh: Difference between revisions
| Line 39: | Line 39: | ||
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. | 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==<ref name="video1">https://www.youtube.com/watch?v=HDj8MMFWmkQ<br></ref> | ||
===Temptation to Add Cool Features=== | ===Temptation to Add Cool Features=== | ||
Revision as of 03:04, 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 facts have been identified, and a lot of 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 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!
Fallacies
Five Fatal Logical Fallacies of Software Development
Fallacy Fallacy
Drawing the conclusion that another engineer's point is incorrect because he cannot adequately defend his position. 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
Justifying or defending a coding practice by citing precedent. 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
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. 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 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 stakeholders happy.
The False Dichotomy
Constraining a problem space to two — and only two solutions. 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 JVM GC pauses, network latencies, etc. Rarely are there only two possibilities when dealing with undiagnosed problems.
Confusing Correlation and Causation
Assuming that because events occur together that one must cause the other. This is another fallacy that tends to be seen when troubleshooting production issues. In such situations, reams of data are analyzed and we humans do what we're best at: 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==<ref name="video1">https://www.youtube.com/watch?v=HDj8MMFWmkQ
</ref>
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:
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">https://www.youtube.com/watch?v=q_A5kAMygOI
</ref>
</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 />