hide

Read Next

How to Estimate like an Adult - A Developer's Guide

Usefully estimating software projects is difficult, but not impossible.

A lack of understanding about why we estimate, what to estimate, and how to estimate leads to a breakdown of trust and communication between developers and managers.

Developers end up feeling guilty that they're not meeting their estimates, and at the same time defensive: they were just estimates after all, right? Managers feel exasperated that everything is taking three times as long as it should. What are they doing all day?

This article is about fixing your estimates, and your estimation process. It's split in to two parts - the part you're reading, titled "How to Estimate like an Adolescent", and the part you're not yet reading, titled "How to Estimate like an Adult - What to Steal from Agile".

As an aside, if you're in a position where someone else is estimating work you're doing, get out. The work will be late, you will be blamed, and you will be miserable. Programming is meant to be fun, and setting yourself up for accusations of professional incompetence and the niggling feeling that maybe you are incompetent is the antithesis of fun. Seriously, get out.

FIRST Robotics

On Flourish

The FIRST robotics season has begun! I'm working with a high school team to build a robot in 6 weeks that will compete in sports-like competitions. Robots compete on random teams of three against other teams, in several qualifying matches and then elimination rounds. The theme for this year is "Aerial Assist", and the game encourages passing and teamwork among alliances, which appeals to me as the Iowa St. basketball team is currently 2nd in assists per game and makes passing a point of emphasis. A nice animation of the 2014 FIRST game is here.

I have been frustrated throughout the preseason of FIRST by the number of students on the team. There are about 90 kids that show up, and with only ~15 mentors the it gets pretty overwhelming. This is much larger than typical FIRST teams.

But, this year, in build season, we are dividing everyone up into "corps", with one mentor per corps. Corps are dedicated to different pieces of functionality in the robot, and combine students who work in mechanical, fabrication, controls, and software. For example, this year we have a shooter corps, a drive corps, a ball-pickup corps, an autonomous corps, among others. The autonomous corps is responsible for getting the robot to work during the autonomous period of the game: everything from mounting a camera system to detect which goal is "hot" to automatically driving the robot around to score the ball and end up at the best place for the teleop part of the game. I'm the mentor for the autonomous corps. Having a smaller group of students who are focused on a specific subset of the functionality is much more enjoyable than having twenty students who are good at code but don't know what task to be working on. Everybody can understand their piece better when the robot functionality is divided up.

We are also using Agile, which I've been advocating. Within Agile, teams write down a backlog of tasks to do, then plan for the week-long "sprint" selecting tasks from the backlog and committing to getting those tasks done. At the start of each day, team members talk about what they did yesterday, what they will work on today, and what is getting in their way, in a short standup meeting. The combination of splitting up tasks into week-long and then further into day-long tasks and taking personal responsibility to get them done also helps keep everybody focused and busy.

Rendering New Theme...