How does one go about the task of writing software?
There is a discussion of these topics at
Different approaches work better for different people, and for different problems. But it's usually worth trying to think about things from different directions, which is in part what the top-down vs bottom-up approaches help you to do.
Once you add in a team of people and want at how to manage a a substantial project, the whole thing turns into a management and engineering problem, worthy of another whole course ... like the one that Justin is doing this term.
A full treatment is beyond the scope of this class. You can see the rang of complications at wikedia: software design.
For an example, consider writing a program that simulates the game of craps, and in particular estimates the odds of winning at craps.
When I teach this course in person, we take one class to write this program together, trying to make these ideas tangible.
For now, I'll just hit some of the high points and then ask you to do this as an assignment.
The first step is to understand the problem. So we look up craps, googling "how to play craps". Ignore the betting aspects; we just want to know what it means to win or lose. The explanation at online-casinos.com/craps/rules gives the basics. All you need to know is which dice roles win, and which lose. One game of craps is either a single roll of the dice, or multiple rolls.
The basic idea is this :
Roll two dice.
A total of 7 or 11 total wins right away.
A total of 2, 3, or 12 total loses right away.
Anything else and you continue to roll the two dice over and over again,
trying to get the same as your first roll and win.
But if you roll a 7 before repeating your first total, you lose.
And there's a lot of betting in the real game, which we will ignore.
We want to write a program which simulates this game, playing it many times, counting the number of wins and losses, and from that giving the odds of winning.
Clearly we need to be able to simulate rolling dice, so that's one place to start. (That's "bottom-up" thinking.)
Here's a possible specification.
(I often start
with something that has the right sort of input and output,
even if the code does the wrong thing. For example,
if the function returns an integer, I'll write return 1 or some other integer as a starting point.
This isn't the right answer, but will at least compile and may let me test
other parts of the program.)
def two_dice():
""" Return the sum of two six sided dice """
# TO DO : google "python random" ; read the docs and find the right random function
# TO DO : write this using python's random numbers.
return 2
Once we have a function to simulate rolling dice , we can simulate one game of craps, following the rules. Another function. This one will have a bunch of "if" statements, a loop (roll over and over again), and some return statements.
def play_craps():
""" Simulate one game of craps. Return True for a win, False for a loss. """
# The rules of craps are ...
# first roll : ...
# following rolls : ...
# TO DO : read about the rules and summarize in English.
# TO DO : write the code that replaces "return False"
return False
Now let's pull back and look at the big picture. We want the odds of winning, which means simulating many games, and computing number_of_games_won / total_number_of_games . And rather than deciding how many games, we could just ask the user. That leads to a top-level program that perhaps looks something like this :
def main():
""" Print the odds of winning at craps """
n_games = ask_user() # TO DO : write ask_user function
games_won = count_wins(n_games) # TO DO : write count_wins() ; use play_craps
odds = games_won / n_games
print(f"Played {n_games} of craps; won {games_won}")
print(f"Odds of winning are {odds}")
And then we have lots of TO DO pieces to go back and work on, and lots of places to test individually.