SMOOCHY Methodology Explained

A couple years ago I commented on a post about Using Object Oriented CSS with Sass on The Sass Way, commenting that at Carpages.ca we use a mash-up methodology called SMOOCHY (Scalable, Modular Object Oriented CSS Hybrid, Yo). It’s a fun name that usually gets a chuckle. I’ve been asked about this a couple times, but wanted to make a more structured explanation about what this means, and what it doesn’t mean. 

We use principles from a number of systems like SMACSS (Scalable and Modular Architecture for CSS) , OOCSS (Object Oriented CSS), BEM (Block Element Modifier). Most of the interest around our solution may be looking for an easy-to-implement incredible system to solve all known development problems, but unfortunately, it’s not that simple. 

The Problem

Developers are curious about methodologies like this because of very specific and often painful needs. Collaboration, multitasking, supporting a codebase for years, and a phenomenon I call “reactionary-code” are all necessary and typical problems a developer and codebase will go through. Without some kind of methodology, problems compound. I think we’ve all been on projects that exemplify pain-points in at least one of these areas. That’s the problem; stakeholders, projects, and code are complex. 

The specific examples listed in the Sass Way post are relatable, and OOCSS does a masterful job of solving them. Patterns are amazing, and I’ve seen teams quickly embrace this.   We have adapted this to our workflow with great success. But OOCSS is not the solution to the problem.

The Not-Solution

I am convinced the bulletproof solution to development woes isn’t SMOOCHY. It’s not OOCSS, SMACSS, Atomic CSS, or any methodology/system. There is no simple answer that will make every project go perfectly. Every project is different–and heck, you are a different developer than what you were a couple months ago. No rigid set of rules will solve all of your development problems. Systems may solve some of your problems, but as you tweak your workflow it’s important to go into this knowing that there is no perfect development utopia. 

Tools are tools. They help; but they are usually only as effective as the one wielding them; and that’s probably you: a human being. Human beings are complex, distracted, fickle, unpredictable, creative, prone to react reflexively, and prone to having bad days. 

The Beginning of a Solution

Complex problems on complex projects made by complex developers for complex stakeholders. The solution has to either be really really complex – or really really simple. I like simple. 

“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.” ~ Bruce Lee

Flexibility has been the key that has made methodologies like SMACSS, OOCSS, BEM and others blend for us. I like to think that when the next big great idea comes out we’ll be ready to borrow from it too. A great workflow (and its team of human beings) needs some space in it for various types of flexibility. Here are a couple I thought of:

• Rules that can be broken
• Allows developers to react reflexively (for bugs or hot-fixes)
• An outlet for intentional quick and dirty code (like a more politically named shames.css, or a framework + theme layers)
• A predictable naming convention that can be built on (and robust enough not to fall apart when a rule is broken)
• A system that can be built upon and scaled with as little thought as possible, or as much as possible. 
• A system that can be changed. If something doesn’t work, can it be removed? Experimentation is a key part of innovation, a system needs room in it for some trial and error.

Big-picture: websites come and go, they won’t be living forever in a museum, they exist to solve actual business problems. As a team we create value for our stakeholders as quickly and well as possible. This approach has helped us to do that. 

Ok ok ok, what about SMOOCHY?

Philosophy about Problems and Solutions aside, here’s the deal with SMOOCHY. It’s a slightly-dorky name. It gets its name from a mash-up of other methodologies; but it’s essentially more than an approach to CSS; it’s our front-end methodology; we adopt what is useful from great ideas, and apply them into our way of working. 

• First let me get this out of the way, the “yo” is just to make the acronym cuter, and has nothing to do with Yeoman. 
• We started our framework with a fork of the penultimate version of Inuit CSS (v5). This gives the basis for most of our fine OOCSS patterns.
• Lent from Inuit, and integrated into all our other styles is the BEM naming convention It’s self-documenting as far as intended context for styles.
• We used the approach to reusing broader patterns, and some prefix naming conventions from SMACSS. 
• Our CSS framework is called Gemini CSS. It pairs nicely with our Object-Oriented JS as well. It’s open source on Github. 

The result is a largely un-opinionated and un-styled framework that we extend at a theme-level through a boilerplate. We rapidly create websites for clients. The investment into our own system yields some great advantages: 

• Development can be very fast.
• Custom site designs may only have a couple hundred lines of custom CSS.
• Code is recyclable from any project. 
• Emmet-esque snippets make markup patterns easy to repeat.
• Old sites are easy to maintain because the code is so uniform.
• Collaboration is easy, in fact within a couple weeks a new-hire is essentially coding the same as anyone veteran in the team.
• The code is essentially self-documenting. 
• Per-site QA time is greatly reduced since so much testing went into the framework. 

It’s the difference between building all your toys from scratch vs starting with a robust Lego collection. Compare Degagne Hyundai, Bernard’s Quality Cars and Carpages.ca. Matt Rose (the engineer behind the Carpages Gemini framework) and I spoke about SMOOCHY and the Gemini Framework at SassTO meetup. You can find some slides and audio here. 

I may be Totally Wrong™ (for your workflow)

That’s how we solve the problems of complexity. It’s not perfect, but it has worked very well for us; and we will continue to evolve it. We are a team of less than ten developers who work together in the same room. One size does not fit all. If any of this (and/or some other combination) is helpful to you and your process I’d love to hear about it! 

Maybe the single greatest thing about the website development community is how openly we share ideas, code, and expertise. It doesn’t all fit together always, but it’s still a lot of fun to share and hear how others get websites built.  

Categorized in: Personal

This post was written by ArleyM