But Will It Work for Me

1
ButWill It Work for Me?

• Kathy Iberle
• October 16, 2002

2
Software Engineering Practices

• I hear about new practices
• At conferences
• In books and magazines
• On the Internet
• From other people
• And I wonder
• would that work for me?

3
Early 1990s

• The One True Way
• Medical Products
• Quality Reliability and Correctness
• Profit Sales Cost
• Good Practices in Medical Products
• Detailed written requirements
• Inspections and reviews
• Exhaustive requirements-based testing
• Release based on readiness criteria

4
Consumer Printers, 1997

• Sketchy written requirements
• Ad-hoc testing
• Release based on ship date
• These people must be crazy!

5
Eventually, I learned

• Quality Reliability and Correctness
• AND Quality Compatibility and Usability
• Profit Sales Cost
• AND Sales happen in a fixed market window
• Different Realities Led to Different Practices

6
Not so Crazy After All.

• Sketchy written requirements
• Reference model
• Ad-hoc testing
• Usability issues
• Compatibility with other software
• Release based on ship date
• Cut features instead of slipping the date

7
Assumptions can be Sneaky

• Practices are based on assumptions about reality
• Its easy to see differences in assumptions
• we ship on the release date
• Its harder to see differences in the realities
• The market window is fixed
• The literature often assumes that the author and
  reader share the same assumptions

8
Practice Cultures

• Practice culture A group of software
  practitioners who share common assumptions about
  reality
• People in similar businesses often share a
  practice culture
• Practice cultures also cut across businesses
• More than one practice culture can appear in the
  same company

9
Important Aspects of Reality

• Type of product
• Business software, firmware, games
• Criticality
• life-critical, business-critical, merely annoying
• Market
• Early adopters, mainstream
• Range of environments
• corporate common operating environment,
  household PCs, U.S. only, worldwide

10
Most Important Reality

• Follow the Money!
• Business Model
• Open-market sales
• Fixed-bid contract
• In-house
• Cost of fixing errors
• Distribute patches over Internet
• Install patches on all clients
• Recall of physical units

11
Exploring Cultural Differences

• What are the primary software engineering
  practice cultures?
• What assumptions do they each make?
• How do those assumptions lead to best
  practices?
• A word about this tour
• The data in this paper is anecdotal, not
  scientific
• Your mileage may vary

12
Software Practice Cultures

• Custom systems written on contract
• Custom systems written in-house
• Commercial software
• Mass-market
• Commercial and mass-market firmware
• Open-Source
• Academic

13
Custom Software Written on Contract

• The oldest and probably biggest community
• Reality
• The company makes money by selling its employees
  time and effort
• Examples Finance, military applications
• Profit (amount bid) (cost to write)
• Software may be business-critical or
  life-critical
• Some Assumptions
• On time within budget is important
• Correctness and reliability is very important

14
Favored Practices

• Written requirements established up front
• The contracts require it
• Lots of people, lots of potential for confusion
• Capability Maturity Model
• Stresses prevention of cost overruns
• UML, Rational Unified Process, Cleanroom
• Large systems, lots of people involved
• Formal Quality Assurance Procedures
• Customers often demand audits

15
Custom Software Written In-House

• Your typical IT department
• Reality
• The company makes money by reducing its costs
• Examples Billing, sales, human resources
• Profit (business costs saved) (cost to
  invent)
• Lower-priority projects can be shelved or
  cancelled mid-stream
• Some Assumptions
• We need to justify our projects and track costs
• On-time and within budget may or may not be
  critical

16
Favored Practices

• Many practices are similar to those of
  contractors that write similar software
• Less documentation
• There are no auditors requiring a paper trail
• Less waterfall, more iterative software
  development why?
• There is no contract that requires up-front
  specifications in order to establish a bid
• We are free to ask whether users really know what
  they want

17
Commercial Software

• A large but less-visible practice culture
• Reality
• Company makes money by selling software to other
  companies
• Examples Medical, networking, telecomm
• Profit (sales) (cost to invent)
• Responsible for fixing post-release defects, yet
  the software has left the premises
• Some Assumptions
• Correctness and reliability are most important
• Documentation for audits may be required

18
Favored Practices

• Tailored versions of CMM and ISO 9000
• Interested in estimation and project planning
• Will not seek certification for certifications
  sake
• Quality Planning, TQM, Inspections Reviews
• Very important to keep defect escape rate down
• Key Customers expert users
• Target users are few and have high expectations

19
Mass-Market Software

• A very visible practice culture
• Reality
• Company makes money by selling software directly
  to consumers
• Examples Word processing, tax returns, games
• Profit (sales) (cost to invent)
• Madison Avenue forces market windows, sizzle
• Software has less potential to do serious damage
• Some Assumptions
• Delivery on-time is critically important
• Pleasing 80 of our customers is good enough

20
Favored Practices

• Good enough decision-making
• Broad range of users we cant please them all
• We can ship patches later on
• Lightweight documentation
• No audits, no contracts requiring documentation
• Implicit requirements often work
• Agile project planning Scrum, Evo, etc
• Handles rapid technology and market changes

21
Firmware

• Includes mass-market and commercial
• Reality
• Company makes money by selling a physical product
• Examples Cars, TVs, cell phones, routers,
  defibrillators
• Profit (sales of product) (cost to invent)
• Cost of post-release bug fixes is enormous
• Software can be life-critical
• Some Assumptions
• Firmware must work reliably and correctly
• Firmware must be ready when product ships

22
Favored Practices

• Quality Planning, TQM, Inspections Reviews
• Very important to have low defect escape rate
• Specialized design methods
• Realtime is very different from batch processing
• Some use of waterfall-style lifecycles
• Synchronizes with the hardware activities
• Developers often do their own testing
• There is no user interface
• Some prototype hardware is dangerous to handle

23
After the trip.

• Weve visited these software practice cultures
• Custom systems written on contract
• Custom systems written in-house
• Commercial software
• Mass-market
• Commercial and mass-market firmware
• For each, we looked at
• their reality
• the assumptions that arise from their reality
• the practices that arise from the assumptions

24
To Evaluate a Practice

• Find the practice culture in which the practice
  originated
• Determine the assumptions relevant to this
  practice
• Compare those assumptions with your own reality
• Decide whether the practice will work for you

25
Where did the Practice Originate?

• Where does the author work?
• Did it appear in a publication targeted at a
  specific practice culture?
• Software Development Magazine
• Crosstalk
• Do the examples suggest a specific culture?

26
Compare the Assumptions with Your Reality

• Does the practice claim to fix a problem that you
  dont have?
• Establish requirements at the beginning of a
  project
• Fixes the problem of how much to bid
• Doesnt handle genuine uncertainty
• Does the practice assume other practices that
  your organization doesnt use?
• Requirements-based Testing
• Assumes the existence of requirements

27
Summary

• Practice cultures are groups of people who share
  assumptions about reality
• A practice is good or bad in the context of a
  particular reality
• Find the context by
• Identifying the assumptions
• Comparing with your own reality
• Dont believe everything you read
• Including this presentation!

28
Have a Good Story?

• Email address at www.kiberle.com

29
What About the Internet?

• Reality is in flux
• Multiple ways to make money
• Traditional in-house software
• Commercial software, purchased by subscription
• E-commerce a business pays for the software but
  the end users are consumers
• Speed sizzle count
• Software started as low-criticality only a few
  years ago but is rapidly moving up the scale
• Availability expectations are increasing rapidly
• Functionality changes are often easy to
  distribute
• Assumptions are in flux, too

30
Favored Practices

• The situation is changing very rapidly
• Practices favored in 2000 might be inadvisable
  today
• Practitioners bring practices from their home
  culture in-house, consumer, commercial
• Some practices dont work any more, some do
• Tendency to throw the baby out with the bathwater
• Iterative development XP, etc is popular
• Users are uncertain of their needs
• Better to get basic functionality out before the
  competition, and beef it up later