I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:
- Breaking things down by value, not by task
- Thinking in terms of “size” (not time)
- Making estimates
I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.
In a previous post, I explored the question: Is your chair your enemy?, based in part on the many recent articles, research reports, and infographics claiming that the simple act of sitting is killing you.
But I recently read David Zax’s FastCompany article, In Defense of Sitting, a humorous counter argument (“Sitting may kill you. But at least you’ll die doing something you love.”) to the widely-published judgement that standing while at task is surely the key to eternal life.
What the summer of 1975 did for sharks, what the fall of 2001 did for anthrax, the last few years have been doing for that seemingly innocuous object: the chair.
Surprises from Chrome
The next day while we were pairing, we opened up Chrome, hit our app, and noticed that our new “date” field had magically turned into a fully-functional date picker!
We were puzzled. We started looking at commit logs, wondering if another teammate had snuck in a little treat without us noticing. Then I tried the app in Firefox… and the date picker disappeared.
Posted in Tools, Web Tagged emberjs
I’ve been an email addict for a long time, but I’ve been working to replace my old, bad habits with new ones. I’ve discovered that managing email well can dramatically improve my productivity.
Old Habits (Letting my email manage me)
I get about 2,000 work-related emails every month (I’ve nearly given up on my personal email account), and my historical approach to keeping an empty inbox was to be always checking and responding to my email.
I’d frequently check email:
- first thing upon waking up
- right before commuting to work
- first thing upon getting to work
- in between meetings or scheduled sessions
- during any free moments or waiting periods
- right before I left work
- while eating lunch or dinner with others
- as a car passenger during family errands
- right before I went to sleep
- in the middle of the night if I woke up
I first looked into simple solutions involving node Cakefiles and static site generators like wintersmith, but I found these solutions lacked the power and flexibility I needed. At this point, through an obscure comment in a Google Talk thread about wintersmith, I heard my first reference to Grunt. Read More
I’m currently working on an Ember.js web application that is a basic CRUD app with a twist — we don’t know all of the form fields or model attributes ahead of time, but rely on a JSON document to specify the names and types of attributes for which we need to render form controls. This presents some interesting challenges, the most significant being that our input elements don’t know what to bind their value to until they are instantiated.
After trying a few different approaches, we settled on using a pair of observers to accomplish what a more direct binding could not in this scenario. One observer watches the input’s
value property and updates the remote property value, and the other observer watches the remote property and updates the input’s
Cut to the chase and check out the jsbin example, or read on for a few more details.
(This example uses Ember.js 1.0.0-RC.1, and we are using the same general solution in 1.0.0-RC.3.)
Recently, a group of people at AO collectively bought a MakerBot Replicator 2. The printer has been going pretty steadily, but not without the teething problems expected in an early-adopter technology.
Poor Extruder Block Design
Makerbot’s stock extruder for the Replicator 2 uses a round delrin plunger mounted on the end of a screw to pinch the filment against the stepper motor’s hobbed wheel to push filament. Delrin has a low enough coefficient of friction that this works great so long as your filament is a constant diameter. In our printing, we’ve found that our extruder occasionaly still skips steps, leaving gaps in the extruded filament.
In one of my previous posts, I described an implementation of miniKanren in Haskell. I have since been improving the implementation.
I am currently working on the third iteration of my logic library. The first one was described by my previous post. The second is in a GitHub repository. I have yet to settle on a design that I really like, but I thought I’d post something about what I’ve been working on.
The key improvements in the second iteration were the ability to easily add custom data types and the addition of a
match function. The custom data type addition was pretty straightforward. Read More
Posted in Languages Tagged haskell
I recently came off a project where it is clear, in retrospect, that we operated in a rush throughout much of the last half of the project. The budget got extended more than once so that we could “just get it out the door.” It was a small project: a month or two initially, then another month part time working on “that last detail” and helping to transition it to the customer’s internal team.
This has led me to the conclusion that, when coming to the end of a budget, deciding under pressure to extend the work for “just another week” is a very bad idea. The technical decisions driven by a project size of six months are probably not the same decisions that you’d make on a one year project. When you find that your schedule is slipping, it’s important to make an honest review as soon as possible.