Fig. 1: If your IDE looks like this,
you're doing it wrong.
- | - | - | - |
Days | Hrs | Mins | Secs |
---|
- Prepared with notes for next discussion?
- On target for evolution deliverables?
- Next evolution presentation/report ready?
- Next out-of-class eval scheduled?
Overview
ECE458-01: Wilkinson 126, TuTh, 1:45PM to 3:00PM
ECE458-02: Wilkinson 126, TuTh, 3:30PM to 4:45PM
If you are attending remotely with the express permission of the instructor, see this Ed post for Zoom link.
Instructor: Dr. Tyler Bletsch
Email: Tyler.Bletsch AT duke.edu
Office Hours: By appointment (but totally fine - feel free to request a meeting)
Teaching Assistants:
- Anshu Dwibhashi (anshuman.dwibhashi AT duke.edu)
- Arjun Sridhar (arjun.sridhar AT duke.edu)
Links
- Forum (Ed)
- Sakai (assignment upload and gradebook)
- Project requirements:
- REDACTED
Schedule
Thu 1/6. Introduction
- Course overview slides
- Find volunteers for coding environment boot camp
- Pick teams and get started!
Tue 1/11. Modern Web Application Programming
- Intro to Web Development
- Finalize volunteers for coding environment boot camp
- Finalize group membership
- Q&A on the project requirements
Thu 1/13. Programming Languages and Frameworks
- Beating the Averages by Paul Graham (the Blub Paradox)
- Your group's first design decision will be which language and framework to implement your project in.
- Part 1: Language bootcamp:
To help, a number of students are asked to research a language/framework and deliver:
- a 4-minute intro presentation, and
- a written one-page quick-start containing links and information for any team that might wish to deploy it.
- NodeJS (Meteor, MeanIO, Sail, Koa, Express, etc.),
- Python (Django, Flask, Pyramid, etc.),
- Ruby (Rails), and
- Java (Spring, GWT, etc.).
Student notes/materials:- TBD
- Part 2: Tradeoff discussion:
After the brief technical intros, our first class discussion will focus on topics to consider in making your language selection. Here are some concrete discussion points to consider:
- What is the "Blub paradox"? Do you suffer from it?
- What language features make a programming language "Good"? Why?
- How do the relative importance of those features change in different situations?
- Consider a handful of programming languages which you know or which were covered—how well (or poorly) do these languages provide the features you described above?
- NOTE: Teams will be presenting their project management plan in five days...
Tue 1/18. Project management
- Evidence-Based Scheduling by Joel Spolsky
- In my experience, bad planning and logistics is just as likely to sink your project as design issues. Let's fix that.
- Each team must identify and report on a tool and/or technique to address each of the following issues:
- Project dependencies, timeline, and opportunities for parallel effort (e.g. Gantt chart?)
- Bug/task tracking and assignment
- Source code control and governance (branching, merging, code review, deployment, etc.)
- Let's discuss some of the planning issues you may encounter.
- What are ALL the steps that will go into a release (evolution) of your softare?
- Is it worth anything to know you're behind schedule? What can you do with that information?
- How could a project's execution be "inefficient"? How can this inefficiency be detected and corrected?
- The above practices are mostly about improving efficiency, but how might they also improve the quality of the final product?
Thu 1/20. Workday
- Stand-up status meeting (quick!)
Tue 1/25. Good Design: What is it?
- Guest panelist: Daniel Holmes, Senior Software Engineer - Development Tools and Services, NetApp
- Basics of the Unix Philosophy from The Art of Unix Programming by Eric S. Raymond
- Sections 5.1 and 5.2 of Chapter 5 of Code Complete by Steve McConnell
- An Incremental Architecture Approach to Building Systems by Jan Stenberg
- DevOps Case Study: Netflix and the Chaos Monkey by C. Aaron Cois
- The primary goal of this course is to get you thinking about how to design software better.
Accordingly, our second class discussion will focus on what we consider to be "Good" design. Here are some concrete discussion points to consider:
- What are the hallmarks of a Good design?
- What are the hallmarks of a Bad design?
- How do these considerations tie into the language features you found desirable?
- How do you plan to ensure good design?
- How can you evaluate the Goodness of your design...
- ...in the planning stages?
- ...in the implementation stages?
- ...when maintaining it?
- If you made bad design decisions, how do you decide between sticking with it and redoing it?
- What is essential complexity? Accidental complexity?
- How do we deal with the essential complexity?
- What might lead us to create accidental complexity?
- Consider the following quote from Neal Ford: "It's the duty of the architect to solve the problems inherent in essential complexity without introducing accidental complexity." How can we do this?
- When we design programs, we actually have two very different tasks: Programming in the Large (PitL) and Programming in the Small (PitS).
In the former, we consider large scale design considerations: modules, their interfaces, etc.
In the latter, we consider design considerations on a much smaller scale: implementation of a module, class, or function.
- Which of your good design/bad design features contribute to PitL, and which to PitS?
- Which of the important language features that you identified earlier are important for PitL vs PitS?
- How do the two tasks relate? Are they mutually exclusive? Serially dependent? Iterative refinements of each other?
- Which is more important: PitL or PitS? Put a different way, if you had to work on a piece of software which did one excellently and one badly, would you prefer good PitL design coupled with poor PitS design or poor PitL and good PitS?
- Which scale of design aspects is easier to modify when requirements change? How does the answer to this question inform our design decisions?
- Deployment is just as important as design, as code run wrong is just as broken as code written wrong.
- What is DevOps?
- Why would you want to automate the deployment process?
- How does automated deployment and testing connect with good design?
Thu 1/27. Effective professional presentations and technical demos
- Guest panelist: David Klem, Solutions Architect, Dropbox.
- The Listener's Bill of Rights by Beryl Pittman
- How to pull off a slick tech demo (in 5 easy steps) by Martin Kleppmann
- You're going to present your first evolution soon. Some questions to ponder:
- You've certainly born witness to bad presentations...what made them bad?
- What defines "professionalism" in a presentation?
- What are some techniques and tricks to help give a smooth presentation?
- In what ways might a speaker lose credibility?
- If you show up to do a presentation and you can't connect to the projector, do you look like a giant fool? (HINT: yes.) What can be done to prevent this?
- Public demos tend to fail with almost magical regularity. What can you do to mitigate this risk?
Tue 2/1. Workday
- Stand-up status meeting (quick!)
Thu 2/3. Evolution 1
- Oral presentations
- Due today by 8am:
- Code for this evolution should be submitted
- This same code should be kept deployed on a production machine
- Your eval meeting should be scheduled
Tue 2/8. Evolution 1 Reflection
- Each team should come prepared to discuss:
- What parts of your design do you think will set you up well for the future? Why?
- What parts of your system are you most worried about going forward? Why?
- How is your project/software management methodology working? Have you had to evolve it?
- After hearing everyone present, we will discuss tradeoffs between different teams' approaches.
Thu 2/10. Testing, Debugging, and Software Quality
- Guest panelist: Mekka Williams, Principal Engineer - Office of the CTO, NetApp
- Software Testing by Sarah Heckman — a primer on the fundamentals
- The case of the disabled logins — an interesting diagnosis of a malfunctioning Linux-based kiosk
- Testing: Systematic testing is an important part of the software creation process.
In a healthy development environment, testing is generally automated and regular, including nightly regression testing and a robust, end-to-end QA effort conducted before release.
Today, we talk about how it fits into the design process.
- Where do tests come from? How does testing differ from debugging?
- How do you automate testing? When should automatic testing occur?
- How can your design decisions simplify (or complicate) testing?
- How do you design for testability?
- How does your testing infrastructure/plan have to change in the face of changing requirements?
- Can you design your testing infrastructure/plans to be more resilient to evolution?
- Debugging: Most programmers spend more time debugging code than writing it. How can our design improve our debugging process?
- When in the programming process is our code must vulnerable to introduction of bugs?
- How can our design decisions reduce (or increase) the prevalence of bugs?
- How can our design decisions simplify (or complicate) debugging?
- What constitutes "good" debugging practices?
- Due today by 8am:
- Project report for evolution 1
Tue 2/15. Workday
- Stand-up status meeting (quick!)
Thu 2/17. User interface design
- User Interface Design Basics from usability.gov
- (Just skim) User Interface Elements from usability.gov
- Effective Visual Communication for Graphical User Interfaces by Suzanne Martin (from 1995).
- 7 Rules for Creating Gorgeous UI (Part 1 only) by Erik D. Kennedy.
- What is the motivation for studying user interface design?
- Have you ever seen a "bad" UI? What made it bad? What are the risks of bad UI design?
- How should your software architecture inform your UI design? How might it inadvertantly influence UI design?
- What design changes have you made to your UI during or since evolution 1? Why?
- How can a UI support both novice and advanced users simultaneously?
- Given the subjective nature of aesthetics, how can we have "rules" in UI design? What rules might change over time, and which might be timeless?
- What is accessibility? How accessible is your software right now?
Tue 2/22. Workday
- Stand-up status meeting (quick!)
Thu 2/24. Evolution 2
- Oral presentations
- Due today by 8am:
- Code for this evolution should be submitted
- This same code should be kept deployed on a production machine
- Your eval meeting should be scheduled
Tue 3/1. Evolution 2 Reflection
Danger! Start Evolution 3 now! Slacking off because spring break is coming is a known killer in this course! Use *all* your time wisely!- Each team should come prepared to discuss:
- Looking back on what you considered your strengths...were they strengths?
- Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
- What parts of your design do you think will set you up well for the future? Why?
- What parts of your system are you most worried about going forward? Why?
- How is your project/software management methodology working? Have you had to evolve it?
- After hearing everyone present, we will discuss tradeoffs between different teams' approaches.
Thu 3/3. Workday
- Stand-up status meeting (quick!)
- Due today by 8am:
- Project report for evolution 2
Tue 3/8. SPRING BREAK (no class)
Thu 3/10. SPRING BREAK (no class)
Tue 3/15. Maintainability and Refactoring vs. Rewriting
- Guest panelist: Rebecca Register, Kernel Software Engineer, NetApp.
- Things You Should Never Do, Part I by Joel Spolsky
- How To Survive a Ground-Up Rewrite Without Losing Your Sanity by Dan Milstein
- You are almost done with the semester, and have just about finished three evolutions of the requirements.
Hopefully you have significant thoughts on maintaining code in the face of changing requirements, the topic of today's discussion:
- What kind of evolutions were most difficult to deal with?
- Can you generalize what makes a specific type of requirement evolution easy or hard to deal with?
- What makes code easy (or hard) to maintain?
- How does this inform our design decisions?
- What is different when you modify code someone else wrote? How do you mitigate these difficulties?
- Did you ever consider a rewrite of all/part of your project? What are the pros/cons of a rewrite vs. a refactor?
Thu 3/17. Workday
- Stand-up status meeting (quick!)
Tue 3/22. Evolution 3
- Oral presentations
- Due today by 8am:
- Code for this evolution should be submitted
- This same code should be kept deployed on a production machine
- Your eval meeting should be scheduled
Thu 3/24. Evolution 3 Reflection
- Each team should come prepared to discuss:
- Looking back on what you considered your strengths...were they strengths?
- Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
- What parts of your design do you think will set you up well for the future? Why?
- What parts of your system are you most worried about going forward? Why?
- How is your project/software management methodology working? Have you had to evolve it?
- After hearing everyone present, we will discuss tradeoffs between different teams' approaches.
Tue 3/29. Technical writing, software documentation, and intellectual property
- Guest panelist: Dr. David L Kaminsky, Technology Specialist, Fish and Richardson.
- The Bill of “Writes” by Beryl Pittman
- Intellectual Property Primer from copyrightlaws.com
- Developers Need to Start Paying Attention to Licenses by Brian Rinaldi
- Are Software Patents Evil? by Paul Graham
- Why software patents are evil by Simon Phipps
- Writing: Your next evolution is due soon, and soon after you will write your reflection report about it.
In this discussion, we are going to talk about what makes good writing versus bad writing, and look for parallels with program design.
Specific discussion points to consider include:
- What are the hallmarks of a well written document?
- How can you tell if what you have written is good or bad? If you identify something as being poorly written, how do you improve on it?
- Compare and contrast good writing and good program design.
- Compare and contrast the process of writing with the process of programming.
- Documentation: most programmers hate writing it, but wish they had more of it to read...
- How much documentation has your team written? What form does this take? Are you happy with it?
- What makes good documentation?
- Documentation takes time, but what are some ways in which it might save more time than it takes?
- Can good code documentation improve the quality of the product from the user's perspective?
- Intellectual property: Code is protected by copyright mediated by licenses, potentially subject to patents, and may contain trademarks and trade secrets. What's up with all that?
- What license is your code under? What license are you subject to via all your dependencies? What about their dependencies, recursively? Are you compliant?
- How can licenses protect us? How can they cause problems?
- When should you pursue getting a software patent?
- Due today by 8am:
- Project report for evolution 3
Thu 3/31. Workday
- Stand-up status meeting (quick!)
- NOTE: Assign subsections of reading for next session's discussion.
Tue 4/5. Teamwork and business stuff: leadership, communication, budgeting, and politics
- Guest panelist: Craig Chadwell, Vice President for Products, SoftIron.
- Guest panelist: Henry Vail, Engineering Product Management Leader, Cisco.
- Chapter 1 of How to Win Friends and Influence People by Dale Carnegie
(and in the interest of time, you'll be forgiven for just skimming some of the more lengthy anecdotes...) - Technical Debt by Steve McConnell
- A assigned subsection from How to Win Friends and Influence People by Dale Carnegie
(one or two of the set {3.1-3.12, 4.1-4.9}. — See here for subsection assignments - Capex vs. Opex, Diffen.com
- Let's discuss how teams affect software design and implementation:
- What benefits does team programming have?
- What difficulties does it introduce?
- How does leadership/governance work on your team, i.e., how are decisions made and disagreements resolved?
- How should you deal with a peer who seems discouraged or you feel may be having trouble contributing?
- How would your approach differ with a peer who you feel could be working harder?
- Whether you're headed to a big corporation, a small startup, or an academic role, it is certain that non-technical business issues will "intrude" on your work.
In my experience, once you pass a certain level of technical expertise, your career will likely be defined by your understanding of leadership, communication, budgeting, and politics.
- What makes a good leader? A poor leader?
- How do you demonstrate leadership potential when you do not yet have a leadership role?
- How might someone fail to convince others even when they're right?
- What motivates decision makers in a business?
- How could software design decisions affect the budgeting of a software project?
Thu 4/7. Workday
- Stand-up status meeting (quick!)
Tue 4/12. Evolution 4
- Oral presentations
- Due today by 8am:
- Code for this evolution should be submitted
- This same code should be kept deployed on a production machine
- Your eval meeting should be scheduled
Thu 4/14. Overall Reflection
- Each team should come prepared to discuss:
- Looking back on what you considered your strengths...were they strengths?
- Looking back on what you considered your weaknesses...were they weaknesses? What did you do about it?
- How did your project/software management methodology work?
- Revisit the previous discussion topics and contemplate how your answers to these questions have evolved.
- What specific lessons about designing for evolving requirements have you gained from the class project and discussions this semester?
- What were the most important of these lessons?
- How can you apply the lessons you learned to design to guard against difficult requirement changes?
- Marketing video due by 11:59pm on Sunday 4/17
Tue 4/19. *OPTIONAL* Party
- *NON-OPTIONAL* Due today by 8am:
- Final project report
- We'll hang out, have food and snacks, etc. I'll reveal the project planning process. You're welcome to attend both sections if you want.
Course overview and policies
In order to experience long-term software development and its effects on maintainability, you will be developing a semester-long software project. The requirements for this project will be released in four phases called evolutions. You will complete the project in groups of four students. Once you set your groups, you may not change them, so choose carefully!The fundamental teaching mechanism at work in this course is reflection: by building a large and evolving software system, you will make decisions; some will turn out well while others may be costly, and that's okay. To get the most out of this course, be mindful of your actions and reflect on lessons learned over time.
Grading
Your grade will be broken down as follows:- Software deliverables (45%):
You will submit the code for each evolution.
However, grading will not be based on code inspection, but on an evaluation of the project in a simulated customer setting and basic functional testing by the teaching staff.
Note that while it is our goal to be as objective as possible, the overall "quality" of the system is what is being assessed, which, in the absence of a 50-page spec, is going to contain some subjectivity.
In other words, the system you deliver must actually be good from a customer perspective, not merely tick all the boxes.
This is especially true for functionality and usability problems that are reported to you that you do not fix over time.
To facilitate the "evaluation" aspect, each group will need to schedule an out-of-class eval session with me before each evolution is due to be held after the due date. Scheduling early is wise...
- Project report (25%):
About a week after each software deliverable, you will turn in a report which will cover two main points:
- A retrospective on how your previous choices on design and logistics impacted your work to meet the current set of requirements. What decisions set you up for success, and why? What decisions turned out to be a trap, and what would you have done differently instead? Focus not only on technical choices (design), but also on logistics (human factors). In the final report of the course, this should include lessons learned among all past evolutions.
- An evaluation of your current design, with an analysis of its strengths and weaknesses going forwards. This section should justify your current design choices, explaining why you think they will be beneficial to you in the long run. If you recognize weaknesses in your current design, you should discuss them—including an explanation of why they are there, and how you plan to fix them in future submissions. As before, also include an analysis of logsitics and manegerial issues, especially if you decide to make a change.
- A brief section summarizing the contributions of each team member.
Ideally, the retrospective section of submission n would connect back to the forward-looking analysis of submission n−1 (i.e., did things you think would be beneficial actually end up helping you? Did the weaknesses you identified come back to bite you? Did you fix your weaknesses this time around?). The timeline below illustrates what the report is expected to cover in terms of evaluation and retrospective:
These documents should be well written and professional. The submission format is PDF.
- Individual Presentation (10%):
Each group member will present one evolution of the project
to the class (there are 4 evolutions, and 4 members per group). This presentation should be
10 minutes in length.
It should feature a very brief demo of the system, but then focus on similar information to the project report (i.e., a reflection on your design and logistical choices).
These presentations should be well prepared and professional.
The presentation rubric is as follows:
- Class Attendance and Discussion (20%):
You are expected to attend class regularly, and participate as appropriate for the type of class day.
There are four main "kinds" of class session, each with differing expectations:
- Discussion: You need to be prepared to participate in discussions of topics related to software design.
Some discussions will include a required reading or two. I've done my best to make these brief+interesting, so I hope you enjoy them.
I recognize the time crunch we're all under and the temptation it creates to come without proper preparation, so to remove this moral hazard, I ask that you bring a page or two of written notes (typed or handwritten) with your thoughts and questions on the topic, which I'll collect at the end. Note: the notes are NOT a summary of the reading, but your thinking on the whole of the topic, including your reactions, opinions, and questions.
- Workday: These start with a a brief stand-up meeting where every team can go over status, blockers, and open questions. Then they're mostly free time to work as a group. However, I'll be using these sessions to interact with you as individuals, understand your contributions, and address any concerns with regard to the class, so they're not optional!
- Presentation: If you're not presenting, you still need to be there to support your team, answer questions that may be put to you during the Q&A, etc.
- Reflection: In the class after an evolution is due, we will reflect on it and encourage inter-team discussion of decisions and their tradeoffs. We will also review the next evolution's requirements and answer any questions or ambiguities that may arise.
- Discussion: You need to be prepared to participate in discussions of topics related to software design.
Some discussions will include a required reading or two. I've done my best to make these brief+interesting, so I hope you enjoy them.
Academic integrity
I take academic integrity extremely seriously. Academic misconduct will not be tolerated, and all suspected violations of the Duke Honor Code will be referred to the Office of Student Conduct (for undergraduates) or the departmental Director of Graduate Studies (for graduate students). A student found responsible for academic dishonesty faces formal disciplinary action, which may include suspension. A student twice suspended automatically faces a minimum 5-year separation from Duke University.The expectations for this course are that anything you turn in (code, project report, etc.) will reflect the work of your group. I expect that you will not copy code/text from or share code/text with other groups, nor have people outside your group write any of this. You are welcome to (and encouraged to!) share design ideas during class discussions. If you choose to use ideas presented by other groups, you should give credit where credit is due: in your written analysis, when you discuss that element of your design, you should note who you got the idea from.
Production server freeze
Starting on the first evolution deadline, you must abide the production server freeze rules:- The production server is frozen from the moment of an evolution's deadline until 7 days before the next evolution's deadline. This is true even after your eval session and after an evolution's grades are posted!
- Frozen means that there can be no code changes, configuration changes, or database content changes. Exceptions are made for the in-class demo and informal uses of the server in the presence of an instructor or TA (e.g., showing us a bug to ask about it)
- During the time that the server is frozen, the server must stay up, and may be accessed by the myself or the TAs at any time. We may revisit past tests or do ad hoc testing.
Equitable labor rule
This is a rule I hope to never have to apply. In the event of a gross imbalance of team member effort (defined as a member contributing at or less than 50% of their share as estimated by the instructor), the instructor reserves the right to multiply that student's score on group assignments by their estimated contribution. Further, the instructor may elect to distribute points lost in this manner among the other members of the group.As an example, assume a group with students A, B, C, and D. If the instructor determines that student D clearly contributed no more than 50% of their fair share on an assignment on which the group got a 60, the instructor may elect to decrease student D's score to a 30 (60*50%), and may further elect to distribute the 30 points so-removed to the three other members, raising their scores to 70 (60+30/3).
For cases where a student's contribution is at or near 0%, this may be done without warning. For cases where there was some significant effort, this action will only be undertaken after significant discussions and a sustained failure to change trajectory over time.
Other issues
Feeling overwhelmed or don't know where to start on something? Come talk to me.Group dynamics issue?: Come talk to me.
Readings I like but couldn't fit into the schedule
- Books recommended by guest panelist Craig Chadwell
- Marketing
- The Challenger Sale: Taking Control of the Customer Conversation by Matthew Dixon and Brent Adamson
- Building a StoryBrand: Clarify Your Message So Customers Will Listen by Donald Miller
- Why We Buy: The Science of Shopping--Updated and Revised for the Internet, the Global Consumer, and Beyond by Paco Underhill
- Human interactions
- Thinking, Fast and Slow by Daniel Kahneman
- Never Split the Difference: Negotiating As If Your Life Depended On It by Chris Voss and Tahl Raz
- What the CEO Wants You To Know: How Your Company Really Works by Ram Charan
- Crucial Conversations by Kerry Patterson et al.
- Marketing
- Readings/talks recommended by guest panelist Daniel Holmes
- Clean Code by Robert C. Martin - All about managing complexity and avoiding bad code "smells"
- Big Ball of Mud by Brian Foote and Joseph Yoder - An insightful paper on high-level software architecture
- Talks from Nickolas Means relating aerospace and industrial anecdotes to software engineering strategies.
- How to crash an airplane - Team dynamics and the value of all voices
- The Original Skunk Works - Building teams that empower individuals for innovation in new areas
- The race to Mach 2.0 at scale - Thinking broadly and intentionally about goals and success over time
- Who Destroyed Three Mile Island? - Thinking about designing safe failure modes in systems
- The building built on stilts - Engineering ethics and what to do when you make a mistake
- Eiffel's tower - Thinking like an engineer entrepreneur
- Usability.gov — The whole site is a fantastic overview of practical UI/UX issues with no nonsense.
- Salary Negotiation: Make More Money, Be More Valued by Patrick McKenzie
- 97 Things Every Software Architect Should Know edited by Richard Monson-Haefel — a collection of very short essays on software architecture and design
- The sad graph of software death by Gregory Brown — How to tell from ticket metrics that you're going to die
- Back to Basics by Joel Spolsky — Shlemiel the painter's algorithm
- Rub a dub dub by Joel Spolsky — An alternative to a code rewrite: a code scrub
- The Joel Test: 12 Steps to Better Code by Joel Spolsky — Cheat sheet of things any good development group should be doing
- Code Complete by Steve McConnell — The whole book is great
- Software Testing by Sarah Heckman — a primer on the fundamentals
- In-depth: Functional programming in C++ by John Carmack — Practicing functional programming can be good even in procedural languages like C++ and time-to-market industries like game development
- The case of the 500-mile email by Trey Harris — A quick read about a bizarre email configuration mystery
- The Five Essential Phone-Screen Questions by Steve Yegge — Concisely covers what a good phone screen (or interview) will cover.
- The Elements of Style by Strunk and White. Compact and essential guidance on writing, and it's like $5 shipped. You'd be a fool not to order one (or at least find a sketchy PDF of it online).
- Envisioning Information and The Visual Display of Quantitative Information, both by Edward R. Tufte — In-depth discussion of how to create diagrams and figures that express information accurately and efficiently.
- Spotify Engineering Culture — a short video series on how Spotify runs their engineering teams.
- Your Product Demo Sucks Because It's Focused on Your Product in The Review — A summary of Robert Falcone's product demo strategies based on his book Just F*ing Demo!
- Product Demos That Sell: How to Deliver Winning SaaS Demos by Steli Efti — A book on tech product demos specifically focused on Software-as-a-Service products
- Demonstrating To Win!: The Indispensable Guide for Demonstrating Complex Products by Robert Riefstahl — A detailed analysis of product demos in a variety of markets.