Article summary
When I was an intern at Atomic Object during the summer of 2002, I started working on a client project my very first day.
The project was a Java desktop app with a fully configurable UI. The app streamed and displayed live data from a separate server process running on a real-time OS. The goal was to provide a dashboard/HUD to an end-of-line test operator running a newly built vehicle through a series of tests for quality assurance. It was easily the largest and most exciting development effort I’d ever been a part of.
Dev Environment
Our team of roughly four interns and two full-time developers used a mix of Linux and Windows for a development environment. Most of us would simultaneously log into a single Linux workstation via separate XWindows sessions.
I quickly realized that, while everyone had their own window manager of choice, everyone was using EMACS — not just the same editor, but the same, shared EMACS configuration and JDK settings. It was an interesting solution to dev environment replication well before tools like Docker were around.
Test-Driven Development
One shared category of EMACS settings was targeted at compiling the current buffer and running their unit tests.
I was immediately introduced to test-driven development when I sat down to work with Atomic’s co-founder, Bill Bereza, on my first day. The concept was foreign to me and felt like coding inside-out at first. However, given how ubiquitous automated tests were in the codebase, I quickly realized it was a core, important practice at Atomic.
Pairing
Pairing was also a core practice supported by the entire team. Looking back, it was key to allowing Atomic to succeed with so many developers new to the profession.
As someone with so much to learn when I started, getting the opportunity to pair with someone who had over a decade of experience meant I could learn as fast as I could possibly absorb knowledge.
From day one, the intrinsic value of pair programming wasn’t questioned or debated. Instead, discussions around pairing tended to focus on how to best harness its benefits to deliver value to our clients.
Story Cards
On my first few projects, we used physical story cards pinned to cork boards. It was an interesting experience to get the opportunity to work with such a physical, low-tech project management system. This format allowed for a lot of experimentation in what metadata we used for user stories as well as how we managed our project management process (since there was no software guiding us to do it in any particular way).
It was really satisfying to go to the backlog board, take a card back to my pair workstation, and put it in the “done” pile once we finished it.
End-to-End Testing
I was able to participate in Atomic Object’s discovery of the value of end-to-end automated test suites. (Many other groups in software dev. were also exploring them at this time.)
During my 1.5 years as an intern, we recognized the need for and built an end-to-end testing framework for Java. The framework was named HASTE (High-level Automated System Test Environment).
I got the opportunity to collaborate with Carl Erickson, Mike Marsiglia, Dave Crosby, and Ralph Palmeron on a paper about this framework, which we submitted to the eXtreme Programming/Agile Universe 2003.
Though the framework wasn’t used much after its creation, our teams recognized the value of automated E2E tests for all projects since. It’s been a critical practice enabling our teams to move quickly and confidently without sacrificing quality whenever deployed effectively.
Getting the opportunity to start my software consulting career at Atomic Object as early as I did was a really special and unique opportunity. A key value that I recall setting us apart from our contemporaries was our focus on practical ways we could deliver high-quality output to our clients.
We weren’t a group of early agile coaches or people looking to think up the next best experimental idea related to the agile space. Instead, we were looking to be the best practitioners we could be — taking what folks like Kent Beck were sharing with our industry and refining it.