Follow The Smells / Be Agile

Over the years I’ve bounced around quite a bit in the engineering world; I’ve found myself actively developing applications on the front-end, middleware, platform, and even munging around in data warehouses. I guess you could call me a “full-stack” engineer.

Recently, I had an excellent opportunity to be the tech-lead for a rewrite into FullContact’s new web-platform dubbed Redboat. During the stretch, I stumbled across a “Code Smell” while digging around the code of an upcoming feature.

In Software Engineering, the term “Code Smell” implies something is fundamentally wrong with code, but you’re not quite sure what it is. Typically an experienced engineer will sense the smell, then follow it until the underlying cause is addressed.

What was particularly interesting about this smell, was the fact that it became apparent that the code itself didn’t smell. In fact, I came to the conclusion that this code shouldn’t be written at all. The design / ux smelled. With no buy-in necessary; The Designer, Product Manager and I came to the same conclusion that the feature would fit nicely within an already awesome part of our product.

This was a big milestone for Redboat. It signaled to me that the Engineering, Design and Product had started to fit well enough together that “Smells” in one aspect of the application could signal issues to others.

I’d never found myself having such a strong capability to detect underlying issues with an application and act on them. I found myself wondering, what the hell happened?

A friend recently linked me to this excellent / controversial talk by Marty Cagan (Great Engineering, Failed Product). The talk surfaced a lot of my career-long frustrations as an Engineer. Marty also led me to the answer of the question above, what the hell happened during Redboat…

• We ditched the roadmap.
• We defined the core idea — Build a web-platform that distills our product into something that is faster and easier to understand.
• We got a Designer, Product Manager and Engineering Team into a separate office to promote collaboration.
• Most Importantly, we empowered the entire team to act as peers and follow “Smells” everywhere. This led to interesting ideas / improvements on the fly.

Looking back, It was the first time in my career as an Engineer where the term “agile” was truly applicable to how the team operated, and not just an arbitrary engineering process.