We discuss scale, risk, and different options with our customers and team members continually throughout the lifetime of a project. Having a visual representation of the conversation points can be very useful.
A well-designed visual makes it easy to identify the highs and lows, draws conversation to the most important points, and helps everyone navigate the problem landscape. It’s hard to replace the way a good visual can connect with visual learners. And, as an added benefit for me, it removes the temptation to just read a slide during a presentation.
A few quick tips before we dig in:
Color matters. I like to browse the palettes on COLOURlovers for inspiration.
Double-check your numbers. It sucks to realize your visual is wrong in the middle of a presentation.
It’s nice if the visual is easy to update to reflect new information. Simple shapes and a straight-forward scale help that a lot.
Carl likes to talk about the worry gene culture at Atomic — our predisposition to turn worries into concrete, positive action. The converse of this behavior, inaction, can quickly lead to unresolved worries piling up. That’s where stress comes in. And despite our predisposition to positive action, we all sometimes need a kickstart in the right direction.
Fortunately, many of our practices at AO already serve to guide us toward the concrete, positive actions we need. And there are other simple things I’ve found that help effectively spur the worry gene into action. Read more on Worry; Don’t Stress…
Vim is a good friend of mine. When we met during my freshman year of college at MTU, we quickly hit it off. I never looked back with any regret at my tiny TI-85 screen, Notepad, or QBasic where I first tinkered with bending computing devices to my whims. Since then I have tried other editors, and even used a few for extended periods for a variety of reasons (e.g., Kate because of its SSHFS and KDE tie-ins, Visual Studio for its strength with all things Microsoft). Still, through it all, Vim has been my go-to editor for nearly 15 years.
I have been using Atom almost exclusively for the past month — without vim-mode. This was an intentional decision on my part. I didn’t have any complaints about how Vim had been working for me prior to picking up Atom. It, along with our built-to-Atomic-tastes configuration, did great navigating the mixed mobile & web project environment I was working in. I was just feeling ready to try something different when Atom came on the scene — something that wasn’t vim and didn’t work like vim. Plus, I dig the name and logo. ;) I figured, at the worst, I’d return to Vim after a while with a renewed appreciation for everything that makes it, well, Vim.
Burn charts have been a staple of Atomic-run projects for quite a while. They’ve also been the subject of much discussion both internally at Atomic and at-large in the Agile development community. The basic concepts are simple, and we’ve found them useful — especially when they are allowed to evolve as we learn how to better engage our customers and teams. I’m going to tell a story of one such evolution.
I’m going to follow the story of a ficticious company, Acme, Inc., working on a custom order management system. Our burn chart experience started simply, as Mike’s example illustrates: one big scope bucket (represented by the blue line), and a team of three working to realize the features represented in our backlog (represented by the green line).
Carl Erickson wrote back in 2009 about his practice of distributing “nice words” from clients to the company at large. It is a practice that continues, and something that I personally love about working at Atomic. It lifts my spirits and makes me proud to be a part of such a highly-praised group. I know I’m not alone in my appreciation for this practice.
Nice words mean so much to all of us in part because they result from hard work. To us, these words are like a flag flying triumphantly atop a newly-constructed castle. Weeks or months of time has often gone into erecting the solid, stone walls. Thoughtful, sometimes difficult, decisions have shaped it for its intended purpose. Throughout the process we’ve sweated the details, pursued knowledge and empathy, and as a team brought a vision to life.
Here at Atomic, we work to maintain our sustainable pace on a number of levels. I typically think of my pace on a weekly granularity because of our team’s iterations, invoicing cycles, and the intervening weekend breaks. There’s a rhythm in which I can feel the ebb and flow of my energy level resulting from the week’s efforts and accomplishments.
Atomic encourages employees to take a consecutive week of vacation at some point during the year, and I recently took 10 days off to travel with my wife and disconnect. Having the opportunity to disrupt the rhythm, to disconnect and re-energize, is important. But it isn’t always easy, especially for people who are deeply engaged with and care about their work (as we do here at AO). Here are a few things that can help make it work. Read more on Ready to Disconnect on Vacation? 6 To-Dos Before Leaving the Office…
My current project involves an Ember.js web application and a JSON+HAL API, and we recently wanted to let administrative users upload an XML file, sourced from a different system, to make filling out a form easier. We didn’t want to upload the file to the API for processing on the server. Following is an example illustrating how we handled the file upload in our Ember.js app, and how we could make this work with a few other file formats.
1. The Upload
Let’s pretend we want to make it easy to upload a list of user information into the application. I’m going to illustrate a method using a file input element for the upload interface. There are other options, like drag & drop, but this met our users’ needs and was simple to implement.
Here are a few tools we’re using on my current project, a non-trivial Ember.js application, to do just that.
I recently had the opportunity to travel up to the fall career fair at my alma mater, Michigan Technological University, with fellow MTU alum and Atomic developer Jeanette Head. We had a great visit. It was exciting to be back on campus looking for engaged, smart software developers to join our team, and I left seriously impressed by the number of great connections we made.
The boundaries between our digital world and physical world blur a little more every day. Our houses and cars are becoming increasingly controlled by computers and connected to the internet at large.
As a software developer and driving enthusiast, I’m particularly interested in the intersection of cars and software. I’m excited by a large number of the improvements in vehicle control and utility these changes have enabled. The stability control system in the Nissan GT-R, for example, is astoundingly robust. Naturally, then, I’m curious about what modern control systems and vehicle communication channels might enable enterprising enthusiasts and makers to accomplish.
But there is a darker side to the connected world as well: people with malicious intent are increasingly able to take advantage of the same systems. Our cars are hackable. The potential impact depends on the vehicle and whether the hacker has physical access to it, but the possibilities range from merely inconvenient to downright dangerous. Read more on Hackable Cars, for Enthusiasts… and Others…