Code Like a Butterfly, Perfect Like a Bee

After reading and practicing a slew of different methodologies in development projects I've noticed an interesting trend emerge, especially when working mid- to large-scale. In an effort to get an initial working example I'll write code very quickly, only slowing on occasion to optimize or clean up a chunk of logic. My initial work will be littered with smelly code, though internally I'll be categorizing and segmenting out the areas for later polishing. I'm starting to think of this type of rapid development in terms of Muhammed Ali's famous quote, 'Float like a butterfly, sting like a bee'.

There are plenty of ways to interpret this quote. I like to think of Muhammed Ali's message as a description of using efficient and optimal ways to get shit done. Whether that's beating down an opponent in a ring or cranking out an application, there are plenty of breakpoints where wheels will start spinning and you just get stuck. By moving rapidly, skipping over those areas, you can keep the big picture goal in mind and circle back to those areas as time permits.

This isn't radically different from some of the practices that I've worked with or discussed here. You still need to focus on readability of your code, especially if you or another person will be circling back in short order to do polishing. This type of coding uses ideas of incremental changes and smelly code, as well as continuous development and rapid prototyping. For me the big change has been my internal expectations. When I first started doing web development I would code from the top of the page down, which meant finding the exact styles and background images first, then moving onto SEO in the <head> tag, followed by thinking of the logic behind the initial headers of the page and the menu/navigation structure… And very quickly getting bogged down by details of the site.

As a quick example - I recently had to build a website at work. It's a simple project with a few dynamic portions, all built off a common open-source CMS/framework. The site needs to have a lot of small sections on the page feeding out data pulled from external sources (relative to the main engine of the framework, that is), be responsive, and have a lot of huge glamour shots. Instead of worrying about all of the different details I simply built the entire framework of the site in a few hours. I used block divs with solid backgrounds to represent the images, Bacon Ipsum as placeholders for the dynamic content (wanted to keep it somewhat PC), and made a few assumptions on the structure of the navigation in order to crank out a prototype weeks before the client expected it. Since I had some time to spare I circled back after the initial build and added responsive styles and practices, again taking a fraction of the expected time. The benefits? This project is way ahead of schedule, the client can view an interactive mockup instead of flat wireframes, and I left specific chunks of smelly code to circle back to in the coming months.

Again, I don't feel like this is groundbreaking or radical compared to a lot of other practices out there, more of an internal mindset. Being good at something is only one aspect of mastering a field, while another is finding the methods that work with you that allow you to quickly and effortlessly execute. This approach allows me to do that, to float lightly over the codebase and circle back and sting (polish) specific areas when the time is right. Plus, it makes a more accessible and fun workflow description than 'code monkey'.