Broadening My Horizons (or How I Moved Outside the Silo and Learned a New Development Methodology)

I’ve been writing software professionally for ten years. Primarily I’ve worked on the web, but I’ve written everything from line-of-business apps to SQL business reports to CMS-based websites. I’ve always worked in small shops with one to three developers. We’ve always been fairly siloed; each of us writing our own software that we were individually responsible for. I don’t think this is uncommon. I’ve known and talked to many developers who work the same way.

I’m sure this is an overstatement, but it feels like every project I’ve created has reached a point where I realized it was getting out of control. Between scope-creep and unforeseen factors, at some point I start dreading maintenance and support. I knew there were methodologies out there that could’ve alleviated this “out of control” situation, but for any number of reasons (lack of time, not an immediate need, lack of familiarity, incompatibility with current processes) I never spent much time looking into them.

But then I joined Don’t Panic Labs.

My first project here was a fairly standard mobile web app. There was nothing in the project I hadn’t done before, but I had never written software using a formal software engineering design methodology (which DPL strictly adheres to). For those not familiar with our approach, watch this video by Juval Lowy titled “The Zen of Architecture”.

DPL uses closed architectures to reduce coupling and promote high cohesion and testability. “Services” interact with one other through simple structures and defined data and operation contracts.

At first, this imposed structure seemed confining. It made some things harder, or at least made them take longer. Some relatively simple tasks, like database access, took me two to three times longer than if I had just done them the way I normally would.

However, as development continued, and I started to get used the process, a few things became apparent:

1. When something broke, I knew exactly where it was. “Containing Volatility” is the catchphrase for this method, and it’s an apt description.
2. When looking at other project code for reference, I could easily find what I was looking for. It was really amazing how readable someone else’s code was.
3. As the project grew, it didn’t get harder to manage. Having some simple rules meant I knew exactly where new code needed to go and where changes should be made.

After a few weeks, I felt like I had really branched out into a new world and had opened a door to allow me to grow as an engineer.

Being introduced to a new method of developing software has been revelatory, to say the least. I always suspected there must be methods that helped teams of engineers be both successful and efficient, but my exposure to such methods had been limited prior to coming to DPL. To be clear, I’m not claiming that DPL’s methodology is the be-all-end-all that fixes all problems for all situations; I’d be foolish to think that. However, learning about it from others on the DPL team has shown me solutions to various problems I’ve worked through in the past. I’ve found the key to success lies in our willingness to always (cliché alert) look outside the box for ways to improve our processes and never settling for “good enough for now”.