Anthony Panozzo's Blog

Ultimate Website

My biggest accomplishment of the year so far has been creating a new website for Ultimate (Frisbee) in the Indianapolis area. I got a basic concept going one Saturday morning, took feedback and talked to stakeholders, and then made a final version with the help of others in Indy. Notable improvements include:

• pictures from Zach Dobson, a professional photographer in Indianapolis, on the front page
• maps of all the fields that are used for pickup games, with up-to-date information about when they are played
• integration with a league manager that has online signups, payments, and Google Maps support to show where fields are
• live streaming of the 2010 Indiana Ultimate high school championships on June 20th

For comparison, you can check out the old site. I'm really happy that people helped out and offered suggestions and improvements to the site. This project is on autopilot now.

When you have something like

// connect to database
code
code
code

This might be an indicator that you can extract the code under the comment into a separate method to make things clearer and more modular.

I whipped together a quick video to somewhat explain this idea.

video platform video management video solutions video player

Title: Managing the Design Factory Author: Donald Reinertsen Length: 288 pages Published: 1997 ISBN-10: 0684839911 ISBN-13: 9780684839912

This book analyzes product development processes from a lean perspective. The author starts by introducing the concept of a "design factory", which shows the differences between lean principles applied to manufacturing and lean principles applied to creating new innovations. The key differences include information arrival processes and the repeatable versus non-repeatable.

This is an idea that I read about in Managing the Design Factory (detailed outline). Around page 226, Reinertsen says:

Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.