SlideShare a Scribd company logo
1 of 71
Fundamental Principles of
Software Development
Nitin Bhide
Thinking Craftsman
http://thinkingcraftsman.in
Some basic guidelines
 This is a ‘Learning Program’ and not a
‘training program’.
◦ Hence your Active Participation is needed.
◦ Participate in discussions
◦ Ask questions/doubts.
◦ If you have not understood some
point/concept, Raise your hand and ASK
 Avoid side conversations
 Avoid phone calls/emails.
June 16 Commercial in Confidence (C) Nitin Bhide 2
Some basic guidelines
 Understand that there are no 'absolute
truths' in software development. Hence
We may disagree with some points/
ideas. And THAT IS OK.
 In dealing with disagreements, focus on
the technical merits.
◦ And not on who said it. (Your company
guidelines, some books etc etc)
June 16 Commercial in Confidence (C) Nitin Bhide 3
Some basic guidelines
You will
not get
these
slides.
So make
your own
notes
June 16 Commercial in Confidence (C) Nitin Bhide 4
The Principles
Fail Fast
TELL, Don’t ASK
Design By Contract
Minimize the Impact of Change
June 16 Commercial in Confidence (C) Nitin Bhide 5
PRINCIPLE 1
: FAIL FAST
June 16 Commercial in Confidence (C) Nitin Bhide 6
Fail Fast
Key to delivering High
quality products (software
/hardware /manufacturing)
June 16 Commercial in Confidence (C) Nitin Bhide 7
Principle behind Agile practices
TDD (Test Driven Development)
Automated Unit Tests
Pair programming
Short development cycles (Sprints)
Continuous integrations
June 16 Commercial in Confidence (C) Nitin Bhide 8
Principle behind Agile practices
 TDD (Test Driven Development)
 Automated Unit Tests
 Pair programming
 Short development cycles (Sprints)
 Continuous integrations
June 16 Commercial in Confidence (C) Nitin Bhide 9
Toyota Production System
 Build a culture of stopping to fix
problems, to get quality right from the
first.
 Use visual control so no problems are
hidden.
June 16 Commercial in Confidence (C) Nitin Bhide 10
Variations
 Fail Faster, Succeed Sooner
◦ By David Kelly, Founder IDEO
◦ It is Core axiom in the field of innovation
design
 Fail early, Fail often
◦ Principle of Disney-Pixar
June 16 Commercial in Confidence (C) Nitin Bhide 11
What is it?
If an error occurs,
Fail Immediately and
Visibly!
• Don’t hide the error
• Don’t postpone reporting
the error
June 16 Commercial in Confidence (C) Nitin Bhide 12
Why “Fail Fast” ?
Error is constrained
• Effects of error are localized.
• Cost of Error is reduced
Easy to detect the reason for Error
• The error is reported where it happened
• Else, if reported late, it is very hard to detect the
source of the error
June 16 Commercial in Confidence (C) Nitin Bhide 13
Cost of Fixing an Error
Cost
TimeError Introduced
Depends on distance between
‘error introduced’ to ‘error reported’
June 16 Commercial in Confidence (C) Nitin Bhide 14
Fail Fast Systems
Fail Early and Fix Early
• Only way to avoid cost associated with
production failures
• Fail-fast systems are usually designed
to stop normal operation rather than
attempt to continue a possibly flawed
process
15
“Failure can be a good thing. If it saves
you from following a doomed path for a
year, you’re glad to have failed early
rather than late.”
Kate Gregory (2005)
Gregory Consulting
June 16 Commercial in Confidence (C) Nitin Bhide 16
FAIL FAST IN SOFTWARE
June 16 Commercial in Confidence (C) Nitin Bhide 17
Why “Fail Fast” ?
Error is constrained
• Data (Userdatabase) is not corrupted
• “Crash is Bad” is not always true.
Easy debugging
• The error is reported where it happened
• Else, if reported late, it is very hard to detect the
source of the error
June 16 Commercial in Confidence (C) Nitin Bhide 18
Why “Fail Fast” ?
Finds bugs early, not later.
• Debugging is ‘unpredictable’. Hence it is
biggest schedule risk.
• Distance between “point of failure” and
“point of reporting failure” usually
determines the time for debugging.
• Fail Fast ensure that this distance is low.
June 16 Commercial in Confidence (C) Nitin Bhide 19
Fail Fast Principle –
Key to robust software
 Bugs are risky and expensive. They are pain in
neck to reproduce and locate
 Failing fast reduces the debugging cost and
pain, significantly.
 Over time, more and more errors will fail fast
 Cost of debugging decreases
 Quality of application improves and the
product becomes robust
June 16 Commercial in Confidence (C) Nitin Bhide 20
Failure types
 User input errors
 Programming errors
◦ Error conditions
◦ Violation of Assumptions
◦ Compilation Errors
June 16 Commercial in Confidence (C) Nitin Bhide 21
User input error
 Tell the user about the error right
away
◦ Don’t do this
In step 8 in a wizard get a message “Can’t
proceed; illegal value for step 2. Start Over”
June 16 Commercial in Confidence (C) Nitin Bhide 22
How to Fail Fast - User Input Errors?
 Ask the user to correct the error
immediately after the error is done
 Don’t postpone it and lose the data the
user has filled till now
 May not have to fail if the user’s intent
can be inferred, but if you have to fail,
do it as above
June 16 Commercial in Confidence (C) Nitin Bhide 23
Programming error – error
condition
 A condition in the software which can
happen
 It is NOT an illegal condition
 It requires special handling by
Application and Usually needs to
reported to User.
◦ Configuration data for the application is missing
◦ Data can’t be retrieved from the database
◦ User tries to do “File Save” on CDROM drive
June 16 Commercial in Confidence (C) Nitin Bhide 24
How to Fail Fast - Error
conditions?
 Present an appropriate message to the user
◦ For a connection failure
 NOT: ORA-03114: not connected to ORACLE
 Rather: “We are unable to connect to the System of Record.
Please check the network connectivity or contact the System
Administrator.”
 User error objects or exception handling
 Workaround may be OK, but if not, fail as
mentioned above
◦ Resource unavailable (e.g., connection not made), wait and
try again (may it gets connected now)
◦ Corrupted data, but reasonable default value available (but
log the issue so that the corrupted data can be fixed)
June 16 Commercial in Confidence (C) Nitin Bhide 25
How to Fail Fast – Error
conditions?
 e.g.,
Public int maxConnections()
{
String property = getProperty(“maxConnections”);
if(NULL == property)
{
throw NullPropertyException;<- Fail fast
}
else
{
return property.toInt();
}
}
June 16 Commercial in Confidence (C) Nitin Bhide 26
Programming error – Violation of
Assumption
 A condition in the software which
should “NEVER” arise
 e.g.,
Char *DuplicateString(const char *iStr)
{
char *StrNew = NULL;
StrNew = (char *)malloc(strlen(iStr) + 1));
-> Should iStr be NULL???
strcpy(StrNew, iStr); …
}
June 16 Commercial in Confidence (C) Nitin Bhide 27
How to Fail Fast – Violation of
Assumptions?
 Fail Fast at time of compilation if
an ‘assumption is violated’
 Typically achieved using language
features/ Compiler checks.
◦ Making a copy constructor/ operator=
private to ensure nobody can create a
copy of the object.
June 16 Commercial in Confidence (C) Nitin Bhide 28
How to Fail Fast - Violation of
Assumptions?
 Assertion is the key
◦ Assertion: Tiny piece of code that checks a
condition and then fails if the condition
isn’t met
 Use assertion
◦ To validate conditions that you expect to
hold at certain points in the code (in other
words – invariants)
◦ Rather than assuming these invariants
hold, you test them explicitly
June 16 Commercial in Confidence (C) Nitin Bhide 29
How to Fail Fast - Violation of
Assumptions?
 Typical locations for using assertion
◦ At the start of a function, to check that the
state in which the function is invoked is as
expected – i.e., to check the precondition (e.g.,
checking the input arguments)
◦ At the end of a complicated procedure, to
check that the result is plausible – i.e., to check
the postcondition
◦ At intermediate locations, to check the sanity
of data of at that point and then proceed ahead
June 16 Commercial in Confidence (C) Nitin Bhide 30
How to Fail Fast - Violation of
Assumptions?
 e.g.,
Char *DuplicateString(char *iStr)
{
Assert(NULL != iStr);<- Should never happen. Responsibility of
the caller function to send valid input
char *StrNew = NULL;
StrNew = (char *)malloc(strlen(iStr) + 1));
-> Should iStr be NULL???
strcpy(StrNew, iStr);
…
}
June 16 Commercial in Confidence (C) Nitin Bhide 31
How to Fail Fast - Violation of
Assumptions?
void SomeFunc()
{
…
Document *pDoc = GetDoc();
Assert(NULL != Doc);
…
int NumData = 0;
NumData = pDoc->GetNumData();
Assert((LowRange <= NumData) && (HighRange >= NumData));
…
CreateDataHandlers(NumData);
…
}
June 16 Commercial in Confidence (C) Nitin Bhide 32
How to Fail Fast - Violation of
Assumptions?
double CalcSqaureRoot(double dValue)
{
double dSqRootVal;
…logic…
Assert((CalcSqaure(dSqRootVal) – dValue) < TOL) <-
SelfCheck!!!
<- Ofcourse CalcSqaure() should be dependable
return dSqRootVal;
}
If dValue comes in as negative value, what should
CAlsSqaureRoot() do???
June 16 Commercial in Confidence (C) Nitin Bhide 33
How to Fail Fast – Compilation
Errors?
 Can the error (of using =, instead of ==), in the
following statement, be found even before it is
executed?
If(Var = NULL)
SomeFunc();
 Make the complier generate an error for such a
scenario. Write the statement as
If(NULL = Var)
SomeFunc();
The compiler will raise an error as something cannot be
assigned to a constant.
June 16 Commercial in Confidence (C) Nitin Bhide 34
Eric Lippert on Assertions
Assertions should document situations that are impossible, in such a manner that if
the allegedly impossible situation comes to pass, the developer is informed.
Exceptions, by contrast, provide a control flow mechanism for exceptional,
unlikely, or erroneous situations, but not impossible situations. For me, the key
difference is this:
 It should ALWAYS be possible to produce a test case which exercises a given
throw statement. If it is not possible to produce such a test case then you have a
code path in your program which never executes, and it should be removed as
dead code.
 It should NEVER be possible to produce a test case which causes an assertion to
fire. If an assertion fires, either the code is wrong or the assertion is wrong;
either way, something needs to change in the code.
That's why I would not replace an assertion with an exception. If the assertion
cannot actually fire, then replacing it with an exception means you have an
untestable code path in your program. I dislike untestable code paths.
June 16 Commercial in Confidence (C) Nitin Bhide 35
Asserts in Mars Rover Software
We originally formulated the rule to require all
functions with more than 10 lines of code
contain at least one assertion.
We later revised it to require that the flight software
as a whole, and each module within it, had to reach a
minimal assertion density of 2%.
The MSL flight software reached an overall assertion
density of 2.26%, a significant improvement over
earlier missions
 Gerard J. Holzmann, Mars Code,
From ACM Communications Feb 2014
June 16 Commercial in Confidence (C) Nitin Bhide 36
Fail Fast Fallacies
 It results in pretty fragile software, which seems to
failing now and then
◦ NO, it fails only if an error occurs (Writing bad code and
putting unreasonable assertions is NOT Fail Fast, it is pure-
plain bad coding)
◦ NO, as the production version has already been stripped of
the errors which should not occur or handles are put in place
to take care of the errors
◦ YES, if the developer or the QA shirk from their respective
duty. The developer is also a stakeholder because he sees the
code and knows much better that QA that what can go wrong
and where can it go wrong. The QA uses the application as
black box and try to emulate the user scenario
June 16 Commercial in Confidence (C) Nitin Bhide 37
Fail Fast Fallacies
 Application should not contain
assertions in the production version
(release version). It is only for debug
version ?????
WHAT DO YOU THINK ?
June 16 Commercial in Confidence (C) Nitin Bhide 38
PRINCIPLE 2 :
TELL, DON’T ASK
June 16 Commercial in Confidence (C) Nitin Bhide 39
“The Paperboy and the Wallet”
By David Bock
The paperboy comes to your door, demanding
payment of Rs 150.00 for the month.
What will you do?
You turn around, and the
paperboy Pulls your wallet
out of your back pocket,
takes the 150 bucks, and
Puts the wallet back.
Instead of asking for the wallet,
the paperboy should instead tell
the customer to pay the Rs
150.00
As absurd as that sounds, many
programs are written in this style,
which leaves the code open to all
sorts of problems (and explains
why The Paper boy is now having
a iPhone, while you use
Micromax)
Code should work the same way
We want to tell objects what to do,
not ask them for their state.
June 16 Commercial in Confidence (C) Nitin Bhide 40
Elevator Interface
You are on 2nd Floor.
You want to go to 1st Floor
Which button to
Press ?
Or
Elevator is on 1st Floor
June 16 Commercial in Confidence (C) Nitin Bhide 41
Elevator Interface
You are on 2nd Floor.
You want to go to 1st Floor
Which button to
Press Now ?
Or
One Elevator is on 1st Floor
Other Elevator is on 3rd Floor
June 16 Commercial in Confidence (C) Nitin Bhide 42
Usually, Interfaces based on ‘TELL’
are more flexible
than interfaces based on ‘ASK’
June 16 Commercial in Confidence (C) Nitin Bhide 43
Tell, Don’t Ask – A Paradigm Shift
Procedural Paradigm
Object Oriented Paradigm
Procedural code gets
information then makes
decisions. (Ask &Decide)
Object-oriented code tells
objects to do things
June 16 Commercial in Confidence (C) Nitin Bhide 44
Mapping Requirements to Classes
Problem
under
Consideration
Requirements &
Objects Identification
Hierarchy of classes
• Problem under consideration can be
broken down into Requirements
• Requirements can be mapped to set
of classes
• If possible, Class Hierarchy can be
created
June 16 Commercial in Confidence (C) Nitin Bhide 45
Tell, Don’t Ask
 TELL objects what you want them to do
 Do not ASK them questions about their state,
make a decision, and then tell them what to
do
 The logic you are implementing is probably
the called object's responsibility, not yours.
For you to make decisions outside the object
violates its encapsulation
June 16 Commercial in Confidence (C) Nitin Bhide 46
Ask Vs Tell In
Object Oriented Paradigm
Ask, then take Decision
Class Rect
--------
-------
------
-----
float Width( )
float Height( )
float w = rect.width(); // ASK for width
float h = rect.height(); // ASK for height
float area = w * h; // Compute area
BAD IDEA
Asking object for it’s values
and then computing something
with those values
Tell, Don’t Ask
Class Rect
--------
-------
------
-----
float Width( )
float Height( )
// TELL me the area
float area = rect.area();
Tell the Object
float Area( )
June 16 Commercial in Confidence (C) Nitin Bhide 47
Think Declaratively,
not Procedurally
 It is easier to stay out of the trap of Asking, if
you start designing classes based on their
responsibilities
 You can then progress naturally to
◦ specifying commands that the class may execute
◦ as opposed to queries that inform you as to the
state of the object
June 16 Commercial in Confidence (C) Nitin Bhide 48
Important considerations
 Freezing Responsibility of a class or
group of linked classes will ease in
◦ Modularizing the code
 Partitioning a program
◦ Abstraction
 Provides Crisply define boundary
 Focuses on outside view of an object
 Separates the implementation from behavior
◦ Encapsulation
 Data and Implementation encapsulation
June 16 Commercial in Confidence (C) Nitin Bhide 49
Important considerations
Get rid of ‘Set/Get’ functions as
much as possible
June 16 Commercial in Confidence (C) Nitin Bhide 50
PRINCIPLE 3 :
DESIGN BY CONTRACT
(DBC)
June 16 Commercial in Confidence (C) Nitin Bhide 51
Design by Contract – History
 The term Design by Contract (DBC) was coined by Bertrand Meyer in
connection with his design of the Eiffel programming language
 The central idea of DBC is a metaphor on how elements of a software
system collaborate with each other on the basis of mutual obligations
and benefits
 The metaphor comes from business life, where a "client" and a
"supplier" agree on a "contract" which defines for example that
◦ The supplier has to provide a certain product (obligation) and is entitled to
expect that the client has paid its fee (benefit).
◦ The client must pay the fee (obligation) and is entitled to get the product
(benefit).
◦ Both parties must satisfy certain obligations, such as laws and regulations,
applying to all contracts
June 16 Commercial in Confidence (C) Nitin Bhide 52
Clients using a Dynamic Link Library
Application
DLL
Exported
Functions define
the Contract
Interfaces
Interface
Application
Interface
Functions define
the Contract
DBC at Various Levels in Software
June 16 Commercial in Confidence (C) Nitin Bhide 53
DBC at Various Levels in Software
OO Abstractions
Client
dc2.foo()
dc1.foo()
Abstract class
Guarantees the
Client for particular
functionality
Base Class
virtual foo() = 0;
Derived Class
DC1
virtual foo();
Derived Class
DC2
virtual foo();
dc1
dc2
Public functions of a Class
Client
Pt.distance( ); Public functions act
as a contract
Class Point
public:
distance( );
private:
geodesicpath( );
pt
June 16 Commercial in Confidence (C) Nitin Bhide 54
DBC at Various Levels in Software
 Device Drivers
 Standards and Protocols
 COM (Component Object Model)
 SOA (Service Oriented Architecture)
June 16 Commercial in Confidence (C) Nitin Bhide 55
DBC at Class / Routine Level
 If a routine from a class in object-oriented
programming provides a certain
functionality, it may
◦ Impose a certain obligation to be guaranteed on
entry by any client module that calls it: the
routine's precondition
◦ Guarantee a certain property on exit: the routine's
postcondition
◦ Maintain a certain property, assumed on entry and
guaranteed on exit: the class invariant
June 16 Commercial in Confidence (C) Nitin Bhide 56
Class Point
public:
distance( );
private:
geodesicpath( );
distance( )
ASSERT
ASSERT
ASSERT
DBC at Class / Routine Level
What does distance expect ? Pre-condition
What does it guarantee ? Post-condition
What does it maintain ? Class invariant
June 16 Commercial in Confidence (C) Nitin Bhide 57
DBC Methodology
 Using the DBC methodology
◦ the program code itself must never try to verify the contract
conditions
◦ whole idea is that code should “Fail Hard/Fail Fast", with the
contract verification being the safety net
◦ DBC's “Fail Hard/Fail Fast", property makes debugging for-
contract behavior much easier because the intended
behaviour of each routine is clearly specified
◦ The contract conditions should never be violated in program
execution: thus, they should be left as it is in the code
June 16 Commercial in Confidence (C) Nitin Bhide 58
PRINCIPLE 4 :
MINIMIZING IMPACT OF
CHANGE
June 16 Commercial in Confidence (C) Nitin Bhide 59
Minimizing Impact of Change
 THE FUNDAMENTAL PRINCIPLE
 Basis Behind All Major Evolutions in
Programming
June 16 Commercial in Confidence (C) Nitin Bhide 60
Contradictory Requirements
 Keep Software Soft => Allow Change
 But Minimize the Impact of Change
June 16 Commercial in Confidence (C) Nitin Bhide 61
Why ?
To achieve this, we design to minimize the
impact of change.
We wish to save time and money, reduce the
introduction of new defects, and reduce the
pain and suffering inflicted on overworked
developers.
June 16 Commercial in Confidence (C) Nitin Bhide 62
How To Minimize Impact of Change
?
1. Isolate code
◦ Orthogonality
◦ Object oriented programming
2. Minimize Dependencies
◦ Maintain Unidirectional dependencies
◦ Avoid circular dependencies
June 16 Commercial in Confidence (C) Nitin Bhide 63
How To Minimize Impact of Change
?
3. Standardize/Define Contracts
◦ Published interfaces
◦ Protocols and Standards
◦ Abstractions
◦ SOA
4. Reuse, Don’t reinvent
◦ Design (design patterns)
◦ Code (Libraries and Frameworks)
◦ OO Concepts like Composition and
Inheritance
June 16 Commercial in Confidence (C) Nitin Bhide 64
How To Minimize Impact of Change
?
5. Continuous Verification (Fail Fast)
◦ Assertions
◦ Automated Tests (Junit, MkODT)
◦ TDD (Test Driven Development)
June 16 Commercial in Confidence (C) Nitin Bhide 65
RECAP
June 16 Commercial in Confidence (C) Nitin Bhide 66
Recap
June 16 Commercial in Confidence (C) Nitin Bhide 67
ANY DOUBTS/QUESTIONS ?
June 16 Commercial in Confidence (C) Nitin Bhide 68
REFERENCES
June 16 Commercial in Confidence (C) Nitin Bhide 69
References
 Fail Fast (http://martinfowler.com/ieeeSoftware/failFast.pdf)
 Eric Lippert’s quote about assertions
(http://stackoverflow.com/questions/1467568/debug-assert-vs-
exception-throwing)
 Tell Don’t Ask https://pragprog.com/articles/tell-dont-ask
 Tell Don’t Ask http://martinfowler.com/bliki/TellDontAsk.html
 On the criteria to be used in decomposing systems into
modules by Parnas (In Communications of ACM 1972 )
https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/c
riteria.pdf
 Design By Contract
(http://en.wikipedia.org/wiki/Design_by_contract)
Contact
Visit the website
http://thinkingcraftsman.in
Feel free to email me at
nitinbhide@thinkingcraftsman.in
Join the discussions on
‘nitinsknowledgeshare’ Google Group
June 16 Commercial in Confidence (C) Nitin Bhide 71

More Related Content

What's hot

DeKnowledge - Try us
DeKnowledge - Try usDeKnowledge - Try us
DeKnowledge - Try usBob Pinto
 
How To Review The Sprints Efficiently
How To Review The Sprints EfficientlyHow To Review The Sprints Efficiently
How To Review The Sprints EfficientlyLemi Orhan Ergin
 
Digital transformation testing.
Digital transformation testing. Digital transformation testing.
Digital transformation testing. Deepak Daniel
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous DeliveryJez Humble
 
7 Wastes of Software Development
7 Wastes of Software Development7 Wastes of Software Development
7 Wastes of Software DevelopmentSunil Bajari
 
Integrating Hardware (Waterfall) and Software (Agile) Development
Integrating Hardware (Waterfall) and Software (Agile) DevelopmentIntegrating Hardware (Waterfall) and Software (Agile) Development
Integrating Hardware (Waterfall) and Software (Agile) DevelopmentIntland Software GmbH
 
How BDD enables True CI/CD
How BDD enables True CI/CDHow BDD enables True CI/CD
How BDD enables True CI/CDRoger Turnau
 
Devops Devops Devops, at Froscon
Devops Devops Devops, at FrosconDevops Devops Devops, at Froscon
Devops Devops Devops, at FrosconKris Buytaert
 
Agile Embedded Software
Agile Embedded SoftwareAgile Embedded Software
Agile Embedded SoftwareJames Grenning
 
Lean Engineering: How to make Engineering a full Lean UX partner
Lean Engineering: How to make Engineering a full Lean UX partnerLean Engineering: How to make Engineering a full Lean UX partner
Lean Engineering: How to make Engineering a full Lean UX partnerBill Scott
 
How testers add value to the organization appium conf
How testers add value to the organization  appium confHow testers add value to the organization  appium conf
How testers add value to the organization appium confCorina Pip
 
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSW
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSWAndy Rachleff, Wealthfront Presentation at Lean Startup SXSW
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSW500 Startups
 
Agile Adoption Story in LGE (Aps2010)
Agile Adoption Story in LGE (Aps2010)Agile Adoption Story in LGE (Aps2010)
Agile Adoption Story in LGE (Aps2010)Woogon Shim
 
Going the Next Step? Agile Values and Hardware Development by Urs Boehm
Going the Next Step? Agile Values and Hardware Development by Urs BoehmGoing the Next Step? Agile Values and Hardware Development by Urs Boehm
Going the Next Step? Agile Values and Hardware Development by Urs BoehmPeter Stevens
 
GMO'less Software Development Practices
GMO'less Software Development PracticesGMO'less Software Development Practices
GMO'less Software Development PracticesLemi Orhan Ergin
 
Test driven development
Test driven developmentTest driven development
Test driven developmentSunil Prasad
 
Doing agile with an ISO-20000 Telco (AgilePT 2015)
Doing agile with an ISO-20000 Telco (AgilePT 2015)Doing agile with an ISO-20000 Telco (AgilePT 2015)
Doing agile with an ISO-20000 Telco (AgilePT 2015)Manuel Padilha
 
Ilari henrik
Ilari henrikIlari henrik
Ilari henrikCodeFest
 
Embedded Extreme Programming - Embedded Systems Conference 2002-2004
Embedded Extreme Programming - Embedded Systems Conference 2002-2004Embedded Extreme Programming - Embedded Systems Conference 2002-2004
Embedded Extreme Programming - Embedded Systems Conference 2002-2004James Grenning
 

What's hot (20)

DeKnowledge - Try us
DeKnowledge - Try usDeKnowledge - Try us
DeKnowledge - Try us
 
How To Review The Sprints Efficiently
How To Review The Sprints EfficientlyHow To Review The Sprints Efficiently
How To Review The Sprints Efficiently
 
Digital transformation testing.
Digital transformation testing. Digital transformation testing.
Digital transformation testing.
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
 
7 Wastes of Software Development
7 Wastes of Software Development7 Wastes of Software Development
7 Wastes of Software Development
 
Integrating Hardware (Waterfall) and Software (Agile) Development
Integrating Hardware (Waterfall) and Software (Agile) DevelopmentIntegrating Hardware (Waterfall) and Software (Agile) Development
Integrating Hardware (Waterfall) and Software (Agile) Development
 
How BDD enables True CI/CD
How BDD enables True CI/CDHow BDD enables True CI/CD
How BDD enables True CI/CD
 
Devops Devops Devops, at Froscon
Devops Devops Devops, at FrosconDevops Devops Devops, at Froscon
Devops Devops Devops, at Froscon
 
Agile Embedded Software
Agile Embedded SoftwareAgile Embedded Software
Agile Embedded Software
 
Lean Engineering: How to make Engineering a full Lean UX partner
Lean Engineering: How to make Engineering a full Lean UX partnerLean Engineering: How to make Engineering a full Lean UX partner
Lean Engineering: How to make Engineering a full Lean UX partner
 
How testers add value to the organization appium conf
How testers add value to the organization  appium confHow testers add value to the organization  appium conf
How testers add value to the organization appium conf
 
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSW
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSWAndy Rachleff, Wealthfront Presentation at Lean Startup SXSW
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSW
 
Agile Adoption Story in LGE (Aps2010)
Agile Adoption Story in LGE (Aps2010)Agile Adoption Story in LGE (Aps2010)
Agile Adoption Story in LGE (Aps2010)
 
Going the Next Step? Agile Values and Hardware Development by Urs Boehm
Going the Next Step? Agile Values and Hardware Development by Urs BoehmGoing the Next Step? Agile Values and Hardware Development by Urs Boehm
Going the Next Step? Agile Values and Hardware Development by Urs Boehm
 
GMO'less Software Development Practices
GMO'less Software Development PracticesGMO'less Software Development Practices
GMO'less Software Development Practices
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Kanban in Action
Kanban in ActionKanban in Action
Kanban in Action
 
Doing agile with an ISO-20000 Telco (AgilePT 2015)
Doing agile with an ISO-20000 Telco (AgilePT 2015)Doing agile with an ISO-20000 Telco (AgilePT 2015)
Doing agile with an ISO-20000 Telco (AgilePT 2015)
 
Ilari henrik
Ilari henrikIlari henrik
Ilari henrik
 
Embedded Extreme Programming - Embedded Systems Conference 2002-2004
Embedded Extreme Programming - Embedded Systems Conference 2002-2004Embedded Extreme Programming - Embedded Systems Conference 2002-2004
Embedded Extreme Programming - Embedded Systems Conference 2002-2004
 

Similar to Fundamental Principles of Software Development

ZendCon 2010 Technical Debt
ZendCon 2010 Technical Debt ZendCon 2010 Technical Debt
ZendCon 2010 Technical Debt enaramore
 
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...Codiax
 
Luncheon 2016-07-16 - Topic 1 - Incident Response Things I wish I Had Known ...
Luncheon 2016-07-16 -  Topic 1 - Incident Response Things I wish I Had Known ...Luncheon 2016-07-16 -  Topic 1 - Incident Response Things I wish I Had Known ...
Luncheon 2016-07-16 - Topic 1 - Incident Response Things I wish I Had Known ...North Texas Chapter of the ISSA
 
DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
DevSecCon Boston 2018: Technical debt - why I love it by Mike BursellDevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
DevSecCon Boston 2018: Technical debt - why I love it by Mike BursellDevSecCon
 
Why change code that works - On Technical Debt and Refactoring
Why change code that works - On Technical Debt and RefactoringWhy change code that works - On Technical Debt and Refactoring
Why change code that works - On Technical Debt and RefactoringCarsten Windler
 
Perfect product architecture in a non-stop start-up
Perfect product architecture in a non-stop start-upPerfect product architecture in a non-stop start-up
Perfect product architecture in a non-stop start-upDroidConTLV
 
Competitive Advantage of Continuous Integration
Competitive Advantage of Continuous IntegrationCompetitive Advantage of Continuous Integration
Competitive Advantage of Continuous IntegrationTim Gifford
 
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)saastr
 
Solving The Agile Contract Puzzle
Solving The Agile Contract PuzzleSolving The Agile Contract Puzzle
Solving The Agile Contract PuzzleAgile Montréal
 
Intranet ROI: 5 Approaches - Bryan Robertson
Intranet ROI: 5 Approaches - Bryan RobertsonIntranet ROI: 5 Approaches - Bryan Robertson
Intranet ROI: 5 Approaches - Bryan RobertsonThoughtFarmer
 
Working Capital Manager
Working Capital ManagerWorking Capital Manager
Working Capital ManagerCashforce
 
Working with Technical Debt
Working with Technical DebtWorking with Technical Debt
Working with Technical DebtSteve Green
 
From Technical Debt to Technical Health
From Technical Debt to Technical HealthFrom Technical Debt to Technical Health
From Technical Debt to Technical HealthMikael Vesavuori
 
Personal Report On Personal Protection Equipment Essay
Personal Report On Personal Protection Equipment EssayPersonal Report On Personal Protection Equipment Essay
Personal Report On Personal Protection Equipment EssayAndrea Olin
 
Technical Debt - Why should you care? (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care? (Agiles Buenos Aires 2011)CI&T
 
How to justify technical debt mitigations in Software Engineering
How to justify technical debt mitigations in Software EngineeringHow to justify technical debt mitigations in Software Engineering
How to justify technical debt mitigations in Software EngineeringAndré Agostinho
 
Data Science: Good, Bad and Ugly by Irina Kukuyeva
Data Science: Good, Bad and Ugly by Irina KukuyevaData Science: Good, Bad and Ugly by Irina Kukuyeva
Data Science: Good, Bad and Ugly by Irina KukuyevaData Con LA
 
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...Tom Breur
 

Similar to Fundamental Principles of Software Development (20)

ZendCon 2010 Technical Debt
ZendCon 2010 Technical Debt ZendCon 2010 Technical Debt
ZendCon 2010 Technical Debt
 
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...
Victoria Albrecht (Springbok AI) – Learnings from Deploying AI and Chatbot Pr...
 
Luncheon 2016-07-16 - Topic 1 - Incident Response Things I wish I Had Known ...
Luncheon 2016-07-16 -  Topic 1 - Incident Response Things I wish I Had Known ...Luncheon 2016-07-16 -  Topic 1 - Incident Response Things I wish I Had Known ...
Luncheon 2016-07-16 - Topic 1 - Incident Response Things I wish I Had Known ...
 
DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
DevSecCon Boston 2018: Technical debt - why I love it by Mike BursellDevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
DevSecCon Boston 2018: Technical debt - why I love it by Mike Bursell
 
Why change code that works - On Technical Debt and Refactoring
Why change code that works - On Technical Debt and RefactoringWhy change code that works - On Technical Debt and Refactoring
Why change code that works - On Technical Debt and Refactoring
 
Perfect product architecture in a non-stop start-up
Perfect product architecture in a non-stop start-upPerfect product architecture in a non-stop start-up
Perfect product architecture in a non-stop start-up
 
Competitive Advantage of Continuous Integration
Competitive Advantage of Continuous IntegrationCompetitive Advantage of Continuous Integration
Competitive Advantage of Continuous Integration
 
Introduction to BDD
Introduction to BDD Introduction to BDD
Introduction to BDD
 
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)
From the Desk of Vanta's CEO: Building to $10MM+ ARR (before taking a Series A)
 
Solving The Agile Contract Puzzle
Solving The Agile Contract PuzzleSolving The Agile Contract Puzzle
Solving The Agile Contract Puzzle
 
Intranet ROI: 5 Approaches - Bryan Robertson
Intranet ROI: 5 Approaches - Bryan RobertsonIntranet ROI: 5 Approaches - Bryan Robertson
Intranet ROI: 5 Approaches - Bryan Robertson
 
Working Capital Manager
Working Capital ManagerWorking Capital Manager
Working Capital Manager
 
Working with Technical Debt
Working with Technical DebtWorking with Technical Debt
Working with Technical Debt
 
From Technical Debt to Technical Health
From Technical Debt to Technical HealthFrom Technical Debt to Technical Health
From Technical Debt to Technical Health
 
Personal Report On Personal Protection Equipment Essay
Personal Report On Personal Protection Equipment EssayPersonal Report On Personal Protection Equipment Essay
Personal Report On Personal Protection Equipment Essay
 
Technical Debt
Technical DebtTechnical Debt
Technical Debt
 
Technical Debt - Why should you care? (Agiles Buenos Aires 2011)
Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)Technical Debt - Why should you care?  (Agiles Buenos Aires 2011)
Technical Debt - Why should you care? (Agiles Buenos Aires 2011)
 
How to justify technical debt mitigations in Software Engineering
How to justify technical debt mitigations in Software EngineeringHow to justify technical debt mitigations in Software Engineering
How to justify technical debt mitigations in Software Engineering
 
Data Science: Good, Bad and Ugly by Irina Kukuyeva
Data Science: Good, Bad and Ugly by Irina KukuyevaData Science: Good, Bad and Ugly by Irina Kukuyeva
Data Science: Good, Bad and Ugly by Irina Kukuyeva
 
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...
Tom Breur - Agile Business Intelligence - accounting for progress - keynote d...
 

More from Nitin Bhide

2nd Techathon in Geometric - 27/28 Feb 2015
2nd Techathon in Geometric - 27/28 Feb 20152nd Techathon in Geometric - 27/28 Feb 2015
2nd Techathon in Geometric - 27/28 Feb 2015Nitin Bhide
 
Do/Doing/Done Is NOT Kanban
Do/Doing/Done Is NOT KanbanDo/Doing/Done Is NOT Kanban
Do/Doing/Done Is NOT KanbanNitin Bhide
 
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...Object Oriented Containers - Applying SOLID Principles to Docker/Container De...
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...Nitin Bhide
 
Daily Habits Of Highly Agile Developers
Daily Habits Of Highly Agile DevelopersDaily Habits Of Highly Agile Developers
Daily Habits Of Highly Agile DevelopersNitin Bhide
 
Collected Wisdom
Collected WisdomCollected Wisdom
Collected WisdomNitin Bhide
 
GUI patterns : My understanding
GUI patterns : My understandingGUI patterns : My understanding
GUI patterns : My understandingNitin Bhide
 
Code Review Checklist
Code Review ChecklistCode Review Checklist
Code Review ChecklistNitin Bhide
 
Iterator - a powerful but underappreciated design pattern
Iterator - a powerful but underappreciated design patternIterator - a powerful but underappreciated design pattern
Iterator - a powerful but underappreciated design patternNitin Bhide
 

More from Nitin Bhide (9)

2nd Techathon in Geometric - 27/28 Feb 2015
2nd Techathon in Geometric - 27/28 Feb 20152nd Techathon in Geometric - 27/28 Feb 2015
2nd Techathon in Geometric - 27/28 Feb 2015
 
Do/Doing/Done Is NOT Kanban
Do/Doing/Done Is NOT KanbanDo/Doing/Done Is NOT Kanban
Do/Doing/Done Is NOT Kanban
 
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...Object Oriented Containers - Applying SOLID Principles to Docker/Container De...
Object Oriented Containers - Applying SOLID Principles to Docker/Container De...
 
Daily Habits Of Highly Agile Developers
Daily Habits Of Highly Agile DevelopersDaily Habits Of Highly Agile Developers
Daily Habits Of Highly Agile Developers
 
Collected Wisdom
Collected WisdomCollected Wisdom
Collected Wisdom
 
GUI patterns : My understanding
GUI patterns : My understandingGUI patterns : My understanding
GUI patterns : My understanding
 
Code Review Checklist
Code Review ChecklistCode Review Checklist
Code Review Checklist
 
CSS Basics
CSS BasicsCSS Basics
CSS Basics
 
Iterator - a powerful but underappreciated design pattern
Iterator - a powerful but underappreciated design patternIterator - a powerful but underappreciated design pattern
Iterator - a powerful but underappreciated design pattern
 

Recently uploaded

AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyRaymond Okyere-Forson
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorShane Coughlan
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilVICTOR MAESTRE RAMIREZ
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionsNirav Modi
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesShyamsundar Das
 
online pdf editor software solutions.pdf
online pdf editor software solutions.pdfonline pdf editor software solutions.pdf
online pdf editor software solutions.pdfMeon Technology
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIIvo Andreev
 
How Does the Epitome of Spyware Differ from Other Malicious Software?
How Does the Epitome of Spyware Differ from Other Malicious Software?How Does the Epitome of Spyware Differ from Other Malicious Software?
How Does the Epitome of Spyware Differ from Other Malicious Software?AmeliaSmith90
 
Streamlining Your Application Builds with Cloud Native Buildpacks
Streamlining Your Application Builds  with Cloud Native BuildpacksStreamlining Your Application Builds  with Cloud Native Buildpacks
Streamlining Your Application Builds with Cloud Native BuildpacksVish Abrams
 
Introduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntroduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntelliSource Technologies
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLAlluxio, Inc.
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmonyelliciumsolutionspun
 
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.Sharon Liu
 
Enterprise Document Management System - Qualityze Inc
Enterprise Document Management System - Qualityze IncEnterprise Document Management System - Qualityze Inc
Enterprise Document Management System - Qualityze Incrobinwilliams8624
 
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...OnePlan Solutions
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfTobias Schneck
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampVICTOR MAESTRE RAMIREZ
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeNeo4j
 
Fields in Java and Kotlin and what to expect.pptx
Fields in Java and Kotlin and what to expect.pptxFields in Java and Kotlin and what to expect.pptx
Fields in Java and Kotlin and what to expect.pptxJoão Esperancinha
 

Recently uploaded (20)

AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human Beauty
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-Council
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspections
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security Challenges
 
online pdf editor software solutions.pdf
online pdf editor software solutions.pdfonline pdf editor software solutions.pdf
online pdf editor software solutions.pdf
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AI
 
How Does the Epitome of Spyware Differ from Other Malicious Software?
How Does the Epitome of Spyware Differ from Other Malicious Software?How Does the Epitome of Spyware Differ from Other Malicious Software?
How Does the Epitome of Spyware Differ from Other Malicious Software?
 
Streamlining Your Application Builds with Cloud Native Buildpacks
Streamlining Your Application Builds  with Cloud Native BuildpacksStreamlining Your Application Builds  with Cloud Native Buildpacks
Streamlining Your Application Builds with Cloud Native Buildpacks
 
Introduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntroduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptx
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
 
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.
20240319 Car Simulator Plan.pptx . Plan for a JavaScript Car Driving Simulator.
 
Enterprise Document Management System - Qualityze Inc
Enterprise Document Management System - Qualityze IncEnterprise Document Management System - Qualityze Inc
Enterprise Document Management System - Qualityze Inc
 
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - Datacamp
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG time
 
Salesforce AI Associate Certification.pptx
Salesforce AI Associate Certification.pptxSalesforce AI Associate Certification.pptx
Salesforce AI Associate Certification.pptx
 
Fields in Java and Kotlin and what to expect.pptx
Fields in Java and Kotlin and what to expect.pptxFields in Java and Kotlin and what to expect.pptx
Fields in Java and Kotlin and what to expect.pptx
 

Fundamental Principles of Software Development

  • 1. Fundamental Principles of Software Development Nitin Bhide Thinking Craftsman http://thinkingcraftsman.in
  • 2. Some basic guidelines  This is a ‘Learning Program’ and not a ‘training program’. ◦ Hence your Active Participation is needed. ◦ Participate in discussions ◦ Ask questions/doubts. ◦ If you have not understood some point/concept, Raise your hand and ASK  Avoid side conversations  Avoid phone calls/emails. June 16 Commercial in Confidence (C) Nitin Bhide 2
  • 3. Some basic guidelines  Understand that there are no 'absolute truths' in software development. Hence We may disagree with some points/ ideas. And THAT IS OK.  In dealing with disagreements, focus on the technical merits. ◦ And not on who said it. (Your company guidelines, some books etc etc) June 16 Commercial in Confidence (C) Nitin Bhide 3
  • 4. Some basic guidelines You will not get these slides. So make your own notes June 16 Commercial in Confidence (C) Nitin Bhide 4
  • 5. The Principles Fail Fast TELL, Don’t ASK Design By Contract Minimize the Impact of Change June 16 Commercial in Confidence (C) Nitin Bhide 5
  • 6. PRINCIPLE 1 : FAIL FAST June 16 Commercial in Confidence (C) Nitin Bhide 6
  • 7. Fail Fast Key to delivering High quality products (software /hardware /manufacturing) June 16 Commercial in Confidence (C) Nitin Bhide 7
  • 8. Principle behind Agile practices TDD (Test Driven Development) Automated Unit Tests Pair programming Short development cycles (Sprints) Continuous integrations June 16 Commercial in Confidence (C) Nitin Bhide 8
  • 9. Principle behind Agile practices  TDD (Test Driven Development)  Automated Unit Tests  Pair programming  Short development cycles (Sprints)  Continuous integrations June 16 Commercial in Confidence (C) Nitin Bhide 9
  • 10. Toyota Production System  Build a culture of stopping to fix problems, to get quality right from the first.  Use visual control so no problems are hidden. June 16 Commercial in Confidence (C) Nitin Bhide 10
  • 11. Variations  Fail Faster, Succeed Sooner ◦ By David Kelly, Founder IDEO ◦ It is Core axiom in the field of innovation design  Fail early, Fail often ◦ Principle of Disney-Pixar June 16 Commercial in Confidence (C) Nitin Bhide 11
  • 12. What is it? If an error occurs, Fail Immediately and Visibly! • Don’t hide the error • Don’t postpone reporting the error June 16 Commercial in Confidence (C) Nitin Bhide 12
  • 13. Why “Fail Fast” ? Error is constrained • Effects of error are localized. • Cost of Error is reduced Easy to detect the reason for Error • The error is reported where it happened • Else, if reported late, it is very hard to detect the source of the error June 16 Commercial in Confidence (C) Nitin Bhide 13
  • 14. Cost of Fixing an Error Cost TimeError Introduced Depends on distance between ‘error introduced’ to ‘error reported’ June 16 Commercial in Confidence (C) Nitin Bhide 14
  • 15. Fail Fast Systems Fail Early and Fix Early • Only way to avoid cost associated with production failures • Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process 15
  • 16. “Failure can be a good thing. If it saves you from following a doomed path for a year, you’re glad to have failed early rather than late.” Kate Gregory (2005) Gregory Consulting June 16 Commercial in Confidence (C) Nitin Bhide 16
  • 17. FAIL FAST IN SOFTWARE June 16 Commercial in Confidence (C) Nitin Bhide 17
  • 18. Why “Fail Fast” ? Error is constrained • Data (Userdatabase) is not corrupted • “Crash is Bad” is not always true. Easy debugging • The error is reported where it happened • Else, if reported late, it is very hard to detect the source of the error June 16 Commercial in Confidence (C) Nitin Bhide 18
  • 19. Why “Fail Fast” ? Finds bugs early, not later. • Debugging is ‘unpredictable’. Hence it is biggest schedule risk. • Distance between “point of failure” and “point of reporting failure” usually determines the time for debugging. • Fail Fast ensure that this distance is low. June 16 Commercial in Confidence (C) Nitin Bhide 19
  • 20. Fail Fast Principle – Key to robust software  Bugs are risky and expensive. They are pain in neck to reproduce and locate  Failing fast reduces the debugging cost and pain, significantly.  Over time, more and more errors will fail fast  Cost of debugging decreases  Quality of application improves and the product becomes robust June 16 Commercial in Confidence (C) Nitin Bhide 20
  • 21. Failure types  User input errors  Programming errors ◦ Error conditions ◦ Violation of Assumptions ◦ Compilation Errors June 16 Commercial in Confidence (C) Nitin Bhide 21
  • 22. User input error  Tell the user about the error right away ◦ Don’t do this In step 8 in a wizard get a message “Can’t proceed; illegal value for step 2. Start Over” June 16 Commercial in Confidence (C) Nitin Bhide 22
  • 23. How to Fail Fast - User Input Errors?  Ask the user to correct the error immediately after the error is done  Don’t postpone it and lose the data the user has filled till now  May not have to fail if the user’s intent can be inferred, but if you have to fail, do it as above June 16 Commercial in Confidence (C) Nitin Bhide 23
  • 24. Programming error – error condition  A condition in the software which can happen  It is NOT an illegal condition  It requires special handling by Application and Usually needs to reported to User. ◦ Configuration data for the application is missing ◦ Data can’t be retrieved from the database ◦ User tries to do “File Save” on CDROM drive June 16 Commercial in Confidence (C) Nitin Bhide 24
  • 25. How to Fail Fast - Error conditions?  Present an appropriate message to the user ◦ For a connection failure  NOT: ORA-03114: not connected to ORACLE  Rather: “We are unable to connect to the System of Record. Please check the network connectivity or contact the System Administrator.”  User error objects or exception handling  Workaround may be OK, but if not, fail as mentioned above ◦ Resource unavailable (e.g., connection not made), wait and try again (may it gets connected now) ◦ Corrupted data, but reasonable default value available (but log the issue so that the corrupted data can be fixed) June 16 Commercial in Confidence (C) Nitin Bhide 25
  • 26. How to Fail Fast – Error conditions?  e.g., Public int maxConnections() { String property = getProperty(“maxConnections”); if(NULL == property) { throw NullPropertyException;<- Fail fast } else { return property.toInt(); } } June 16 Commercial in Confidence (C) Nitin Bhide 26
  • 27. Programming error – Violation of Assumption  A condition in the software which should “NEVER” arise  e.g., Char *DuplicateString(const char *iStr) { char *StrNew = NULL; StrNew = (char *)malloc(strlen(iStr) + 1)); -> Should iStr be NULL??? strcpy(StrNew, iStr); … } June 16 Commercial in Confidence (C) Nitin Bhide 27
  • 28. How to Fail Fast – Violation of Assumptions?  Fail Fast at time of compilation if an ‘assumption is violated’  Typically achieved using language features/ Compiler checks. ◦ Making a copy constructor/ operator= private to ensure nobody can create a copy of the object. June 16 Commercial in Confidence (C) Nitin Bhide 28
  • 29. How to Fail Fast - Violation of Assumptions?  Assertion is the key ◦ Assertion: Tiny piece of code that checks a condition and then fails if the condition isn’t met  Use assertion ◦ To validate conditions that you expect to hold at certain points in the code (in other words – invariants) ◦ Rather than assuming these invariants hold, you test them explicitly June 16 Commercial in Confidence (C) Nitin Bhide 29
  • 30. How to Fail Fast - Violation of Assumptions?  Typical locations for using assertion ◦ At the start of a function, to check that the state in which the function is invoked is as expected – i.e., to check the precondition (e.g., checking the input arguments) ◦ At the end of a complicated procedure, to check that the result is plausible – i.e., to check the postcondition ◦ At intermediate locations, to check the sanity of data of at that point and then proceed ahead June 16 Commercial in Confidence (C) Nitin Bhide 30
  • 31. How to Fail Fast - Violation of Assumptions?  e.g., Char *DuplicateString(char *iStr) { Assert(NULL != iStr);<- Should never happen. Responsibility of the caller function to send valid input char *StrNew = NULL; StrNew = (char *)malloc(strlen(iStr) + 1)); -> Should iStr be NULL??? strcpy(StrNew, iStr); … } June 16 Commercial in Confidence (C) Nitin Bhide 31
  • 32. How to Fail Fast - Violation of Assumptions? void SomeFunc() { … Document *pDoc = GetDoc(); Assert(NULL != Doc); … int NumData = 0; NumData = pDoc->GetNumData(); Assert((LowRange <= NumData) && (HighRange >= NumData)); … CreateDataHandlers(NumData); … } June 16 Commercial in Confidence (C) Nitin Bhide 32
  • 33. How to Fail Fast - Violation of Assumptions? double CalcSqaureRoot(double dValue) { double dSqRootVal; …logic… Assert((CalcSqaure(dSqRootVal) – dValue) < TOL) <- SelfCheck!!! <- Ofcourse CalcSqaure() should be dependable return dSqRootVal; } If dValue comes in as negative value, what should CAlsSqaureRoot() do??? June 16 Commercial in Confidence (C) Nitin Bhide 33
  • 34. How to Fail Fast – Compilation Errors?  Can the error (of using =, instead of ==), in the following statement, be found even before it is executed? If(Var = NULL) SomeFunc();  Make the complier generate an error for such a scenario. Write the statement as If(NULL = Var) SomeFunc(); The compiler will raise an error as something cannot be assigned to a constant. June 16 Commercial in Confidence (C) Nitin Bhide 34
  • 35. Eric Lippert on Assertions Assertions should document situations that are impossible, in such a manner that if the allegedly impossible situation comes to pass, the developer is informed. Exceptions, by contrast, provide a control flow mechanism for exceptional, unlikely, or erroneous situations, but not impossible situations. For me, the key difference is this:  It should ALWAYS be possible to produce a test case which exercises a given throw statement. If it is not possible to produce such a test case then you have a code path in your program which never executes, and it should be removed as dead code.  It should NEVER be possible to produce a test case which causes an assertion to fire. If an assertion fires, either the code is wrong or the assertion is wrong; either way, something needs to change in the code. That's why I would not replace an assertion with an exception. If the assertion cannot actually fire, then replacing it with an exception means you have an untestable code path in your program. I dislike untestable code paths. June 16 Commercial in Confidence (C) Nitin Bhide 35
  • 36. Asserts in Mars Rover Software We originally formulated the rule to require all functions with more than 10 lines of code contain at least one assertion. We later revised it to require that the flight software as a whole, and each module within it, had to reach a minimal assertion density of 2%. The MSL flight software reached an overall assertion density of 2.26%, a significant improvement over earlier missions  Gerard J. Holzmann, Mars Code, From ACM Communications Feb 2014 June 16 Commercial in Confidence (C) Nitin Bhide 36
  • 37. Fail Fast Fallacies  It results in pretty fragile software, which seems to failing now and then ◦ NO, it fails only if an error occurs (Writing bad code and putting unreasonable assertions is NOT Fail Fast, it is pure- plain bad coding) ◦ NO, as the production version has already been stripped of the errors which should not occur or handles are put in place to take care of the errors ◦ YES, if the developer or the QA shirk from their respective duty. The developer is also a stakeholder because he sees the code and knows much better that QA that what can go wrong and where can it go wrong. The QA uses the application as black box and try to emulate the user scenario June 16 Commercial in Confidence (C) Nitin Bhide 37
  • 38. Fail Fast Fallacies  Application should not contain assertions in the production version (release version). It is only for debug version ????? WHAT DO YOU THINK ? June 16 Commercial in Confidence (C) Nitin Bhide 38
  • 39. PRINCIPLE 2 : TELL, DON’T ASK June 16 Commercial in Confidence (C) Nitin Bhide 39
  • 40. “The Paperboy and the Wallet” By David Bock The paperboy comes to your door, demanding payment of Rs 150.00 for the month. What will you do? You turn around, and the paperboy Pulls your wallet out of your back pocket, takes the 150 bucks, and Puts the wallet back. Instead of asking for the wallet, the paperboy should instead tell the customer to pay the Rs 150.00 As absurd as that sounds, many programs are written in this style, which leaves the code open to all sorts of problems (and explains why The Paper boy is now having a iPhone, while you use Micromax) Code should work the same way We want to tell objects what to do, not ask them for their state. June 16 Commercial in Confidence (C) Nitin Bhide 40
  • 41. Elevator Interface You are on 2nd Floor. You want to go to 1st Floor Which button to Press ? Or Elevator is on 1st Floor June 16 Commercial in Confidence (C) Nitin Bhide 41
  • 42. Elevator Interface You are on 2nd Floor. You want to go to 1st Floor Which button to Press Now ? Or One Elevator is on 1st Floor Other Elevator is on 3rd Floor June 16 Commercial in Confidence (C) Nitin Bhide 42
  • 43. Usually, Interfaces based on ‘TELL’ are more flexible than interfaces based on ‘ASK’ June 16 Commercial in Confidence (C) Nitin Bhide 43
  • 44. Tell, Don’t Ask – A Paradigm Shift Procedural Paradigm Object Oriented Paradigm Procedural code gets information then makes decisions. (Ask &Decide) Object-oriented code tells objects to do things June 16 Commercial in Confidence (C) Nitin Bhide 44
  • 45. Mapping Requirements to Classes Problem under Consideration Requirements & Objects Identification Hierarchy of classes • Problem under consideration can be broken down into Requirements • Requirements can be mapped to set of classes • If possible, Class Hierarchy can be created June 16 Commercial in Confidence (C) Nitin Bhide 45
  • 46. Tell, Don’t Ask  TELL objects what you want them to do  Do not ASK them questions about their state, make a decision, and then tell them what to do  The logic you are implementing is probably the called object's responsibility, not yours. For you to make decisions outside the object violates its encapsulation June 16 Commercial in Confidence (C) Nitin Bhide 46
  • 47. Ask Vs Tell In Object Oriented Paradigm Ask, then take Decision Class Rect -------- ------- ------ ----- float Width( ) float Height( ) float w = rect.width(); // ASK for width float h = rect.height(); // ASK for height float area = w * h; // Compute area BAD IDEA Asking object for it’s values and then computing something with those values Tell, Don’t Ask Class Rect -------- ------- ------ ----- float Width( ) float Height( ) // TELL me the area float area = rect.area(); Tell the Object float Area( ) June 16 Commercial in Confidence (C) Nitin Bhide 47
  • 48. Think Declaratively, not Procedurally  It is easier to stay out of the trap of Asking, if you start designing classes based on their responsibilities  You can then progress naturally to ◦ specifying commands that the class may execute ◦ as opposed to queries that inform you as to the state of the object June 16 Commercial in Confidence (C) Nitin Bhide 48
  • 49. Important considerations  Freezing Responsibility of a class or group of linked classes will ease in ◦ Modularizing the code  Partitioning a program ◦ Abstraction  Provides Crisply define boundary  Focuses on outside view of an object  Separates the implementation from behavior ◦ Encapsulation  Data and Implementation encapsulation June 16 Commercial in Confidence (C) Nitin Bhide 49
  • 50. Important considerations Get rid of ‘Set/Get’ functions as much as possible June 16 Commercial in Confidence (C) Nitin Bhide 50
  • 51. PRINCIPLE 3 : DESIGN BY CONTRACT (DBC) June 16 Commercial in Confidence (C) Nitin Bhide 51
  • 52. Design by Contract – History  The term Design by Contract (DBC) was coined by Bertrand Meyer in connection with his design of the Eiffel programming language  The central idea of DBC is a metaphor on how elements of a software system collaborate with each other on the basis of mutual obligations and benefits  The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which defines for example that ◦ The supplier has to provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). ◦ The client must pay the fee (obligation) and is entitled to get the product (benefit). ◦ Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts June 16 Commercial in Confidence (C) Nitin Bhide 52
  • 53. Clients using a Dynamic Link Library Application DLL Exported Functions define the Contract Interfaces Interface Application Interface Functions define the Contract DBC at Various Levels in Software June 16 Commercial in Confidence (C) Nitin Bhide 53
  • 54. DBC at Various Levels in Software OO Abstractions Client dc2.foo() dc1.foo() Abstract class Guarantees the Client for particular functionality Base Class virtual foo() = 0; Derived Class DC1 virtual foo(); Derived Class DC2 virtual foo(); dc1 dc2 Public functions of a Class Client Pt.distance( ); Public functions act as a contract Class Point public: distance( ); private: geodesicpath( ); pt June 16 Commercial in Confidence (C) Nitin Bhide 54
  • 55. DBC at Various Levels in Software  Device Drivers  Standards and Protocols  COM (Component Object Model)  SOA (Service Oriented Architecture) June 16 Commercial in Confidence (C) Nitin Bhide 55
  • 56. DBC at Class / Routine Level  If a routine from a class in object-oriented programming provides a certain functionality, it may ◦ Impose a certain obligation to be guaranteed on entry by any client module that calls it: the routine's precondition ◦ Guarantee a certain property on exit: the routine's postcondition ◦ Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant June 16 Commercial in Confidence (C) Nitin Bhide 56
  • 57. Class Point public: distance( ); private: geodesicpath( ); distance( ) ASSERT ASSERT ASSERT DBC at Class / Routine Level What does distance expect ? Pre-condition What does it guarantee ? Post-condition What does it maintain ? Class invariant June 16 Commercial in Confidence (C) Nitin Bhide 57
  • 58. DBC Methodology  Using the DBC methodology ◦ the program code itself must never try to verify the contract conditions ◦ whole idea is that code should “Fail Hard/Fail Fast", with the contract verification being the safety net ◦ DBC's “Fail Hard/Fail Fast", property makes debugging for- contract behavior much easier because the intended behaviour of each routine is clearly specified ◦ The contract conditions should never be violated in program execution: thus, they should be left as it is in the code June 16 Commercial in Confidence (C) Nitin Bhide 58
  • 59. PRINCIPLE 4 : MINIMIZING IMPACT OF CHANGE June 16 Commercial in Confidence (C) Nitin Bhide 59
  • 60. Minimizing Impact of Change  THE FUNDAMENTAL PRINCIPLE  Basis Behind All Major Evolutions in Programming June 16 Commercial in Confidence (C) Nitin Bhide 60
  • 61. Contradictory Requirements  Keep Software Soft => Allow Change  But Minimize the Impact of Change June 16 Commercial in Confidence (C) Nitin Bhide 61
  • 62. Why ? To achieve this, we design to minimize the impact of change. We wish to save time and money, reduce the introduction of new defects, and reduce the pain and suffering inflicted on overworked developers. June 16 Commercial in Confidence (C) Nitin Bhide 62
  • 63. How To Minimize Impact of Change ? 1. Isolate code ◦ Orthogonality ◦ Object oriented programming 2. Minimize Dependencies ◦ Maintain Unidirectional dependencies ◦ Avoid circular dependencies June 16 Commercial in Confidence (C) Nitin Bhide 63
  • 64. How To Minimize Impact of Change ? 3. Standardize/Define Contracts ◦ Published interfaces ◦ Protocols and Standards ◦ Abstractions ◦ SOA 4. Reuse, Don’t reinvent ◦ Design (design patterns) ◦ Code (Libraries and Frameworks) ◦ OO Concepts like Composition and Inheritance June 16 Commercial in Confidence (C) Nitin Bhide 64
  • 65. How To Minimize Impact of Change ? 5. Continuous Verification (Fail Fast) ◦ Assertions ◦ Automated Tests (Junit, MkODT) ◦ TDD (Test Driven Development) June 16 Commercial in Confidence (C) Nitin Bhide 65
  • 66. RECAP June 16 Commercial in Confidence (C) Nitin Bhide 66
  • 67. Recap June 16 Commercial in Confidence (C) Nitin Bhide 67
  • 68. ANY DOUBTS/QUESTIONS ? June 16 Commercial in Confidence (C) Nitin Bhide 68
  • 69. REFERENCES June 16 Commercial in Confidence (C) Nitin Bhide 69
  • 70. References  Fail Fast (http://martinfowler.com/ieeeSoftware/failFast.pdf)  Eric Lippert’s quote about assertions (http://stackoverflow.com/questions/1467568/debug-assert-vs- exception-throwing)  Tell Don’t Ask https://pragprog.com/articles/tell-dont-ask  Tell Don’t Ask http://martinfowler.com/bliki/TellDontAsk.html  On the criteria to be used in decomposing systems into modules by Parnas (In Communications of ACM 1972 ) https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/c riteria.pdf  Design By Contract (http://en.wikipedia.org/wiki/Design_by_contract)
  • 71. Contact Visit the website http://thinkingcraftsman.in Feel free to email me at nitinbhide@thinkingcraftsman.in Join the discussions on ‘nitinsknowledgeshare’ Google Group June 16 Commercial in Confidence (C) Nitin Bhide 71

Editor's Notes

  1. Check http://www.codinghorror.com/blog/2012/03/visualizing-code-to-fail-faster.html
  2. http://www.ssireview.org/blog/entry/fail_faster_succeed_sooner/ http://flyingmonkeytv.wordpress.com/tag/fail-fast/
  3. http://www.gregcons.com/KateBlog/CommentView.aspx?guid=f9765002-18bf-4531-a3a3-01ca3afdf560
  4. Check the article on ‘http://tagswap.net/pub/docs/OOP_Principles_TellDontAsk.pdf’ (has some good code samples)
  5. You have to press the elevator button based on where you want to go (up or down). Don’t worry about where the ‘elevator’ currently is. (Tell) If you look where elevator currently is (Ask) and then decide whether ‘elevator’ needs to come up or down (ask&decide). Let ‘elevator’ take the decision how best to serve you. Both approaches work when there is only one elevator. But when there are two elevators and only one up/down button common to both elevator, Ask&Decide approach fails.