Category Archives: Development
Heisenberg’s Key Performance Indicators
How do you objectively measure the progress of a software engineering team from iteration to iteration when they are so many variables (human and otherwise)?
The Standing Desk
Dave, My OPOWER colleague switched from a normal office desk & chair situation to a standing desk more than a year ago and ever since, I’d been considering doing the same. For my entire programming career, I’ve had terrible posture in my chair and tended to do “the maxell pose” where my wrists are resting [...]
Tweaking the Agile Calendar
For the first five iterations, the dev team had been following this schedule:
- Iteration N, Week 1 = Design for iteration N and 2nd week of QA for iteration N-1
- Iteration N, Week 2 = Development
- Iteration N, Week 3 = Development
- Iteration N, Week 4 = 1st week of QA for iteration N
- Iteration N, Week 5 / Iteration N +1, Week 1 = 2nd week of QA for iteration N, design for iteration N + 1
Agile impressions, 5 iterations in…
I'm assuming from the amount of hype out there that if a development team isn't using "Agile" right now, they probably feel like the one kid on the block who didn't have a Nintendo (with the Duck Hunt option, of course).
Well, we here at OPOWER loved our Duck Hunt, so we've been attempting to use "Agile" for the last 5 months or so. Agile means a lot of things to a lot of people, so I'll spell out what it means for us and then reflect on some of the pros, cons, and room-for-improvement in our practice.
Well, we here at OPOWER loved our Duck Hunt, so we've been attempting to use "Agile" for the last 5 months or so. Agile means a lot of things to a lot of people, so I'll spell out what it means for us and then reflect on some of the pros, cons, and room-for-improvement in our practice.
Move meetings to move developers
Here's the scenario:
You cruise in to the office at 8:45, get your coffee, check the reddits, and ignore that email from your parents asking if their computer picked up a virus because McAfee won't stop popping up a tooltray icon helpfully informing them that they're totally vulnerable. Right around 9:15, you get motivated to tackle that 2 point user story for the current iteration.
You head over to the wiki, check out the specs for the requirement, find out what the Trac ticket number is and see if there are any comments with last minute advice or dependencies. None? Good. . . let's get started!
New Developer Law
NEW LAW FOR DEVELOPERS:
If you throw an exception about some connection being refused, you'd better damn well put what connection you were attempting to make in the exception message.
What inspired this law? Thanks for asking.
Subversion Branching “Good” Practice
I am relatively new to Subversion — well, two years into using it now, but this is the first project I have used it on. Subversion, like any tool, has its quirks and works best when you really know how to use it. When I started, I treated the "trunk/branches/tags" directory structure exactly like a directory structure. It took me a little playing around until I stumbled on what I would call a best practice. When I checkout a new project, I do it like so:
svn co http://domain.com/svnroot/project/trunk project
That way, when I go to the project directory, I do not have to then go into the trunk directory to get to my files.
The Cheated Frogs of Vim
We're still too small of a company to have more than 1 or 2 logical groupings of the development team, and before today they've been basically "the web team" and "everyone else." Of course, there's a lot of cross-pollination and everything nowadays ultimately manifests itself somehow as "'web".
Still, the "everyone else" paint brush was wearing thin. In addition to the "web team", we had "the scale team" (a.k.a "Ops R&D") and "the AMI team" and "the core team" and "the report team". . .but most of those were "teams" averaged size 1 and their membership varied from iteration-to-iteration.
Maven-izing Google’s Data Client Java Library