Taking inspiration from Katie Patrick, I'm building an app to help people make less trash.
It's tempting to dive in and code, especially when you're planning a relatively small application. The catch is, that's how you end up with unfixable design flaws and spaghetti code. I went ahead with some standard planning tools.
Planning the first draft, I produced these user stories. Not set in stone, just something to work with.
Based on the user stories, I put together a conceptual object model.
Planning probably paid off. My first instinct was that the
would reference a single
Household, which in turn keeps track of the number
of people and general location notes. The
Trash records would just link
back to the
But - what happens to all the stats if the user updates the
Trash record that originally came from a house of 4 people could
retroactively end up claiming it only served 2, and there would be no way to
catch it. Can't have that.
You could make every
Trash record store all the
Household details, but that
makes for a lot of data duplication. I've settled on making the
effectively immutable behind the scenes; if the user decides to change details,
they'll actually get a new
Household that will be assigned to future
You might notice I chucked out some ideas from the original user stories. Not accidental. Some things (teams) might come back, but would have been overkill for a first iteration. Others (household income) I decided against. Wealth shouldn't entitle you to pollute more.
Here's a pass at what the main tracking page will look like.
That's plenty to work with. Next up ... write some code.