The logic of estimating
At work, we estimate all of our projects and the process never seems to work that well. We break things up into features and then to requirements and then sort them into iterations and then break them apart further into tasks and then try to estimate the tasks. It all takes a long time and I don’t think the estimates are much better than making a gut call. I’d say its a 4 to 6 month project.
As I have been thinking of the problem I had a realization. Estimating is a problem.
Assumptions:
- If a range of time is given for a project, the project will not be completed until the far end of that range has been reached. E.g. If I say the project will take 4 to 6 months, then the project will most likely take 6 months.
- When asked to estimate, it is human nature to give higher estimates than the actual time it will take to complete. This is particularly true if there are issues with missing your estimates. E.g. If a task takes one day, we estimate its completion at two days.
- x = the actual time it will take to complete a project
- y = the time to estimate a project
- z = the estimated time to complete a project
- x < z
- x = 5 months
- y = 1 month
- z = 7 months
- Only estimate if it is necessary.
- Stakeholders should encourage transparency by not punishing missed estimates, but
rather by helping teams become more accurate. - Teams should minimize the time it takes to estimate by estimating requirements or features rather than tasks. Keep the estimates simple and high-level.
Interior Decorators and Plumbers
The other day, a co-work (developer) explained to a high school student (visiting our office to learn about IT careers) that User Experience is basically like being an interior decorator. I told her that I often describe what she does as being like a plumber in the building that I am responsible for architecting. When will programmers finally understand?
My save the date
This is the save the date that I designed for you wedding. It was inspired by something I was working on. 
My Wedding Invites
Here are the invites I designed for my wedding. The shape was inspired by an invite I found on the web that I have since lost track of. 
Colonial Life Policy Holder Site
Colonial Life’s Policyholder site had not been updated significantly since 1998 and it was greatly in need of a visual redesign, new functionality, better user experience and a technology upgrade. The new site incorporates Sitecore’s CMS, HTML5/CSS3, SOA services and a lot of .NET. It’s easy to maintain due to the technology platform we developed, it contains workflows so business areas can author their own content, but its our customers who benefit the most. The site is easy to use: you can access your policies or claims with just a few clicks. If the customer still has trouble, we created context sensitive FAQs and tips. The new look is friendly and happy, changing how our customers feel when they interact with the company.
- Managed the team responsible for the site
- Creative Director for the project
- Created the initial site architecture and wireframes
Stilllife in America
Still Life in America is a body of photography produced by Charles H. Traub over the last decade. It spans many trips and many states and highlights both a unique side of America and the unique way in which Charles H. Traub sees America.
The interactive experience of the Still Life in America project is an ongoing collaboration between me and my father. Over the years, it has had multiple incarnations the most recent is concurrently being exhibited it China and New York.
Still Life in America 2 HTML5 Version
Still Life in America 1 Flash Version
