CS 458 - Week 4 Lecture 2 - 2016-09-15

*   MMM Chapter 2
    *   why are scheduling problems so rampant?
        *   poorly-developed estimation techniques
        *   optimism ("all will go well")
        *   confusion of effort with progress
	    *   based on the assumption that people and
	        months are interchangeable
        *   sometimes you can't make the customer wait
        *   poor monitoring of schedule progress
        *   dangerous tendency to add warm bodies when	
            scheduling crises occur

    *   3 stages of creative activity
        *   idea
	*   implementation
	*   interaction

        ...when do bugs in our ideas become apparent?
	   often only during implementation or even interaction;

    *   the person-month as a unit for measuring the size of
        a job is a dangerous and deceptive myth.
	It implies that people and months are interchangeable.

        *   partitioning a task among multiple people
	    requires extra communications effort,
	    maybe more training,
	    maybe more intercommunication

*   Brooks scheduling rule of thumb (written in 1975 that he mentioned
    having used successfully for a number of years):
    *   1/3 of the schedule for planning (including design)
    *   1/6 for coding
    *   1/4 for component test and early system test
    *   1/4 for system test, all components in hand

    *   more time for planning than one might think
    *   more time for debugging/testing than one might think

    |  KNOW THIS!
    v

*   BROOKS'S LAW
    *   Adding people to a late software project makes it
        later.
        *   adding people when a project is already late
	    INCREASES the total effort in at least three ways:
	    *   the work and disruption due to the
	        repartioning itself
            *   training the new people
            *   the added intercommunication

       *   yes, this might be an "outrageous oversimplification"
           (p. 25) -- BUT, it is a rule of thumb that is
	   TOO OFTEN true...

----
more on Extreme Programming

*   unit testing -
    writing the TESTS for a module/chunk of code
    BEFORE it is written

    *   are tools such as JUnit, PyUnit, CppUnit, SQLUnit..

    *   the idea: clarify what you think need to do
        before you actually do it
	(maybe also realize issues/pitfalls you need to
	watch out for...!)

*   acceptance testing -
    *   MIGHT be written by the customer?! BUT should
        at least be in terms the customer would
	understand and agree with --

	does this version of the system satisfy/fulfill
	the user stories being implemented for
	this version?

	...acceptance tests seek to test if this is
	the case;

	(is the software acceptable to the customer?)

    *   does the system have the required features,
        and do they work correctly?

*   "test infected development" 
    *   must test sooner or later --
        sooner focuses you!

    *   early testing is HEAVILY stressed in the
        agile methodologies, including Extreme programming;

        ... the HEART of extreme programming??

*   simple design - 
    *   YAGNI - "You Aren't Going to Need It"
    *   do the simplest thing that could possibly work
        ... design simply, and remove complexity at every stage

    *   (this part DOES worry/scare some software engineers!)
        *   many are not comfortable with emergent design   
        
    *   no functionality is added early
    *   refactor whenever and wherever possible

*   spike solutions
    *   create these to reduce risk
    *   a very simple program to explore potential solutions

*   release planning
    *   customer AND programmers meet to negotiate what
        user stores/features will be in the next
	release, the next iteration;

    *   involves BOTH in choosing features and estimating time
    *   what's the difference between
        "not enough time" and "too much to do"?
        *   can't change the number of hours in a day,
	    might be more able to change how much is expected
	    to be in a next release;

    *   Pick 3 from: cost, quality, scope, time
        *   pick 3, because you can't have all 4

    *   programmers determine, for each user story,
        *   how long to develop/implement that story

    *   customers determine what stories are, at that
        point, most desired to be implemented next,
	and when they want that "next";

*   WITHIN an iteration,
    *   start with an informal meeting each "day",
        determining status, issues,
	what will be worked on that day;

*   I've seen the opinion that Extreme Programming
    works best with teams of up to about 20 programmers;
    *   may work best for small- to moderate-sized
        teams?

    *   needs a client willing the be involved, also

*   USER STORIES 
    *   something the system needs to do
    *   1-3 sentences -- not meant to be long
    *   written IN the customer's terminology,
        (may BE written by the customer),
	without techno-syntax

    *   the unit of functionality in an Extreme Programming
        project!
    *   should be
        *   understandable to customers AND developers
        *   TESTABLE
        *   VALUABLE to the customer
	*   SMALL ENOUGH that the developers can
	    implement SEVERAL in an iteration