Digital Design and Development

Who am I?

• My name is Jelani (jeh-lah-nee)

• I'm an instructor and software developer.
• I have a degree in Computer Science from New York University.
• I've led product development for startups and non-for-profit companies.
• I'm passionate about making programming accessible to more people.
• Worked teaching MBA's how to code for over 3 years.

What are we learning?

Previously

• In the previous version of this course, we taught students who had never seen a line of code before to write and deploy full-stack Ruby on Rails apps.
• We would with a simple app idea and would learn the bare minimum of what's needed about various technologies (HTML, CSS, JavaScript) to make that idea real.
• After 10 weeks students were able to build some pretty impressive projects:
  • Duet - App for finding musicians to practice or perform with.
  • Social Salons - App where you can record your past salons visits and explore new popular nail styles.

The catch

• Learning how to code was a lot of very difficult work.
• One of the most difficult parts was learning the syntaxes of writing code, which wasn't our main goal.
• Plus, most students don't go on to write code after the course is over.
• But building applications yourself is the best way to understand how applications work, and so learning how to code was necessary to achieve a deeper understanding of applications.
• ...or so we thought.

We ran some experiments

• We wanted to see if we could achieve a similar level of learning in less time.
• We ran a couple abbreviated courses in the EMBA program at Booth.
• That course is 5 days instead of 10 weeks.
• We were able to distill the course into something successful with less programming.
• Students said the most valuable skill they learned in both the long version and the short version was domain modeling.

• We're going to learn domain modeling.

• To practice those skills we will building functional prototype applications.

• When prototyping, we'll touch on different software development concepts and technologies so you're familiar with the parts of the entire development process.

The current course

• This is an experimental and new course.

  • ​We've made some adjustments after last quarter to improve the experience.

  • We're trying more new things this quarter.

  • Inevitably, there will still be some rough edges and things that don't work well. I apologize in advance 🙏

• ​This course is question-driven.

The current course

"This course will allow MMMs to bring usable prototypes to life, no matter their level of technical expertise"

"This course is not about finding one right answer, but elegant solutions to complex problems"

Course Goals

How are we going to get there in 5 weeks?

• What is domain modeling?
• How will we build applications?

Before that...

What is Domain Modeling?

What is Domain Modeling?

• Has anyone heard this term before? Can anyone give me a definition?
• Our definition will be: The process developers go through to construct an understanding of the problem that they will be writing software to solve, and what the software needs to do.
  • When you code write to solve a problem there is no room for ambiguity.
  • That means developers have to plan out every possible interaction.
  • This requires a very deep understanding of the problem.

• A model is simplified version of the real thing — otherwise it wouldn't be helpful.
  • Think about a map.
  • Or a patient in a hospital.
  • You need to make decisions about what information is important and should be included in the data model and what to omit.
• Similarly, it's not our goal to understand or encode the problem domain in perfect detail. We need to come up with an abstraction that is good enough to solve the problem, and that we can effectively and efficiently describe in software.

We "model" real things as data

Why Domain Model?

• In an ideal world, the developer and the domain expert/product owner/client (henceforth, "domain expert" — the person who knows the idea best) would be the same person, so that the domain modeling process is unnecessary.
• In the real world, most of the time the developer is not the domain expert, so domain modeling is essential — otherwise they'll build something that the domain expert didn't intend.
  • Good Iteration vs Bad Iteration
• Domain modeling helps:
  • Reduce cost
  • Clarify scope
  • Manage risk

How are we going to prototype?

• Programming is very time consuming to learn.
• We'll be using two different low code/no code tools to build our applications using visual drag and drop interfaces.
  • One for designing and building our backend.
  • One for designing and building our frontend.

What you'll be able to build

General Course Structure

Assessments

• In class
  • Due at the beginning of next class.
• Homework
  • Due at the beginning of next class.
  • Building prototypes, reinforcing in-class topics.
• Late penalty
  • 15% penalty for all late submissions.

Each day we’re going to give you a finished app, and you have to determine the data model.

The data models will increase in complexity

We're going to learn and practice technical skills such as...

Identifying what screens and features we need

source

Designing data models

• Callbacks/Notifications
• Validations
• Algorithms/Calculations

Identifying business logic

Prototype Applications

Previously

• Key Learning Takeaways:

  • Understand the general, platform-independent patterns of how applications work.
  • Communicate more effectively and credibly with developers on their teams.
  • Develop a builder’s eye for problems that can be solved with technology.
  • Prioritize features more intelligently by developing a better feel for their costs.
  • Be empowered with a new, powerful, and just plain fun creative outlet.

• We're excited to get there!

• Our goal is to achieve 95% of the learning of the original course:

  • in a much shorter time frame

  • with a lot less friction

The current course

Who's going to help us?

• Patrick Mckernin
• Raghu Betina

Where do we start?

Different Types of Software

• You can domain model any kind of software:
  • Embedded
  • System
  • Utility
  • Application
• We’ll be learning how to domain model by building the most commonly used type of software— Application Software

What software do you use most often?

The kind of software applications that I use most frequently look like this...

"More and more major businesses and industries are being run on software and delivered as online services — from movies to agriculture to national defense.

Many of the winners are Silicon Valley-style entrepreneurial technology companies that are invading and overturning established industry structures.

Over the next 10 years, I expect many more industries to be disrupted by software, with new world-beating Silicon Valley companies doing the disruption in more cases than not."
 

— Marc Andreesen, "Why Software Is Eating the World" (2011)

Everything starts with a URL

URL

Step 1: Type in a URL

STEP 3: Profit!

STEP 2:

Where do we start?

• We're going to start with the data.

• The heart of any application is the information it is keeping track of.
• Users, tweets, and who-follows-who in Twitter.
• Listings, bookings, and messages in Airbnb.
• Venues, reviews, and ratings in Yelp.

• In addition to figuring out what information we need to keep track of we also need to design a good set of tables to organize that information.
• Think of domain modeling as making a mental map of the problem space that we're trying to come up with a solution for.
• Until you have a rough map of the problem and a direction you want to head in, there's no point writing any code. So this is where we're going to start our learning journey too — database design and data modeling.

Database

• A "database" is the software we use to store information. It is just a set of 2D tables; don't let the fancy name throw you. 
• However, I don't want you to think about databases as software at all. Try to think of them as just paper.

Database

• Whatever information we need to power our applications, we need to be able to figure out a way to store it in 2D tables, as if we were storing them in paper tables.
• Whatever logic we need to solve our users' problems with that information, we have to be able to describe how we'd do it as humans, given paper tables.
• Computers are just faster at doing it than us, but it will be the same operations — looking up data that's relevant to a certain user, ordering things in certain way, filtering things by certain criteria, etc.

• We (the developers) figure out the main things, or nouns, in our problem space and make a table for each.

• We add columns to each table for each attribute of the thing we need to keep track of.

• Our users create (or read, or update, or delete) rows.

• We say "create, read, update, or delete" so often — these are the fundamental 4 operations that all user actions map to — that we abbreviate it to CRUD.

• 80%+ of the functionality of most SaaS applications is CRUD. This is what we will focus on learning how to build.

An approach to data modeling

Caveat #1

• Our users actions should not trigger creating tables or columns; only rows. We, the developers, will create all tables and columns up front, when we design and deploy the application.
• Users can CRUD a million rows per second if they want to. They just can't add tables or columns.

Caveat #2

• We will only store one value per cell.

• A value can be a long blob of text, like a bio; but it can't be multiple bios for different people.

Must See Movies

• Okay, this is all pretty abstract. Let's look at some examples.

• Lets examine an application that we'll build in class. It's a very simplified version of the iMDB (the Internet Movie Database).

• Click around it for a minute and then try to imagine — if you had to design tables to store all of the information required to power that app, what would they be? What columns would they have? Think of questions.

Movies

Movies

Movies

Directors

Movies

Actors

Movies

Lines

Actors

Movies

Roles

22

22

23

23

26

87

89

88

88

91

Records and Relationships

Check assignment in Canvas

What are the associations?

• Cities and Neighborhoods
• Courses and Students
• Photographers and Photos
• Bands and Venues
• Contractors and Clients
• States and Senators
• Groups and Members

One-to-Many or Many-to-Many?

When you're deciding, ask yourself: "Can one x have many y? Can one y have many x?"

(The answer is usually: it depends on what you're building. Justify it.)

If One-to-Many, which table gets the foreign key column?

If Many-to-Many, what’s a good name for the join table?

Break

Let's talk about the Syllabus

• Identify: What information does the application need to keep track of?
• Where is that information coming from (our users? government dataset? etc)
• How would I keep track of that information on paper, such that I could answer the "question" that each feature represents by looking through my tables?
• Try to remember that computers can't do anything that we couldn't do by looking through paper tables (they do it much faster, of course). It all comes down to recordkeeping.

Our goal

• On paper, we could add new tables and columns if we wanted to while recordkeeping.
• But, in an app, we can't add tables or columns while recordkeeping. We (the developers) create all of the tables and columns up front.
• After we deploy the app, users only create, read, update, and delete (CRUD) rows in our tables.
• Users can CRUD a million rows per second if they want to. They just can't add any tables or columns.

Caveat #1

• On paper, we could write down more than one value in each box.

• But in our database, we will only store one value per cell.

• A value can be a long blob of text, like a bio; but it can't be multiple bios for different people.

• For one thing, this will save a lot of trouble when it comes to retrieving the values later, and having to figure out where one value ends and the next one begins.

• There are other important reasons to avoid multiple values in a single cell as well.

Caveat #2

1. What table contains the immediate information looking for?
2. Which column are you looking in?
3. What value are you trying to find in the specified column?
4. What are you doing with the filtered results?
   1. Do you need to count a list of records?
   2. Do you need a specific value from one of the columns?
   3. Do you plan to use the results in another query?

Queries should generally be in the format of:

Photogram

• Please visit this application.

• You can sign in with any of the following (all of their passwords are password):

  • alice@example.com
  • bob@example.com
  • carol@example.com

• This is a simple clone of Twitter, but with photos. Itʼs a public social network where anyone can follow anyone (and they donʼt have to follow you back)

• Accounts are all public.

• If you had to design 2D tables to store all of the information required by Photogram, what would they look like?

Part 1: Try to design a database for Photogram

Test your design by adding some "sample data" (a few users e.g. "alice", "bob"; a few photos; etc) to your tables, and verify that the following operations are possible:

ERD and Ideas

• Live slides
• Non-live slides