I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

M. David's articles

  1. Sass and Bourbon Neat for Lightweight Semantic Grids

    If you’re already a fan of Sass and Bourbon, you’re going to love Neat – a lightweight, semantic grid system that works seamlessly with Bourbon and Sass, from the same folks at Thoughtbot who wrote Bourbon. In case all this sounds new to you, Sass is a preprocessor for CSS that can help improve your […]

  2. 4 Warning Signs that Your Team’s Agile Process Stinks

    Getting used to doing things in an agile way can be challenging for everyone in an organization, from the senior management all the way to the core team engineer.

    But applying agile is more than a matter of blindly following the rituals, filling out the artifacts and labeling people with the roles.

    An agile organization needs to embody the philosophy of agile in order to get real value out of the process. Otherwise, agile can become a stand-in for whatever buzzword management technique happens to be popular, and will only serve to obscure any real problems that may exist.

    In order to recognize potential agile process issues and address them, it’s helpful to have a set of signals to follow. Here are four signals I’ve learned to look for–I call them “process smells.”

  3. 5 Ways to Improve Your Sass with Bourbon

    If you write a lot of CSS, there’s a good chance you’re already familiar with Sass. Sass is one of the best ways to preprocess your CSS so you get the advantage of cleaner, DRYer, more maintainable code. And Sass alone can get you pretty far.

    But one of the best things about Sass is that it leaves room for third-party developers to create extensions that can accelerate your Sass experience even further. One of the lightest and most powerful tools I’ve come across to enhance Sass is Bourbon.

    Bourbon is a library of Sass mixins, functions, and add-ons that pick up where the Sass preprocessor leaves off, to provide you with a wealth of convenient functionality that you’re sure to appreciate in your Sass workflow. If you’re not familiar with Bourbon, I’ve written a step-by-step introduction to installing Sass and Bourbon, which you can take a look at to get you started.

    Once you have Bourbon installed, Here are a few of my favorite ways to take advantage of the Bourbon library in your daily Sass coding.

    1. Font Formats

    With all the different browsers, and the different font formats, a large chunk of code is needed to declare a new font face in your CSS. But font faces provide so much versatility when developing sites, whether you’re just adding a catchy headline font, or incorporating a versatile icon font that can save you tremendous bandwidth over individual bitmaps, while rendering vector-sharp images at different sizes.

    In order to support all in-use browsers, you need to create font files in a variety of different formats, and then reference all of them in your CSS before you even start to use your font. The browsers will be smart enough to know which one you can use in that particular session, but you need to reference all of them to make your site robust. The CSS to invoke the font face you looks like this:

    [code language="css"]
    @font-face {
    font-family: My-Font;
    font-weight: normal;
    font-style: italic;
    src: url('/styles/fonts/myfont.eot');
    src: url('/styles/fonts/myfont.eot?#iefix') format('embedded-opentype'),
    url(/styles/fonts/myfont.woff') format('woff'),
    url('/styles/fonts/myfont.ttf') format('truetype'),
    url('/styles/fonts/myfont.svg##My-Font) format('svg');

    All that just so that you can use the font you want for your headlines:

    [code language="css"]
    h1, h2, h3 {
    font-family: 'My-Font', sans-serif;

    Bourbon provides a very convenient mixin for Sass that lets you define a new font family quickly and easily. As long as you use consistent naming for your font files, and upload them to your server in the same directory, Bourbon will take care of all of that repetitive CSS, and give you the same robust CSS you saw above with this simple bit of code:

  4. What’s the Point of Agile Points?

    One of the first questions I always get asked when I’m talking to someone who is new to scrum is this: Why use points to estimate the effort involved in completing a story, instead of estimating in hours or days?

    Points seem arbitrary, and hard to see how they can help a team with its real-world concerns, like meeting deadlines.

    Hours and days, on the other hand, can be easily understood, measured, and weighed against practical external requirements.

    Additionally, one of the key rewards that gets teams interested in implementing an agile workflow is the promise that they can learn to accurately estimate the amount of work the team can do in a certain number of days or weeks. Points seems like a step back from that goal.

    So why use points?

    There is a practical, measurable, real-world value to using a relative estimation tool like points.

    To illustrate this, let’s set up two imaginary teams–one that uses hours to estimate effort and one that uses points.

  5. Why Agile Sprints Are Not Tiny Waterfalls

    One of the first questions that comes up when a team is introduced to scrum is the difference between a sprint and a waterfall.

    Traditional waterfall development happens from beginning to end in the sequence that’s easy to understand, and at first glance, agile process sprints can appear as if they’re simply shorter versions of the exact same workflow.

    There are comparisons, but this kind of reductionism overlooks many of the true advantages of agile development.

    Respecting the differences can help your team–and the people looking on from outside of your team–get a better understanding of agile and how it works.

  6. Getting Started with Sass and Bourbon

    In this article, I hope to get you started with precompiling, or preprocessing, your CSS by showing you how to install Sass and Bourbon, and discussing how to make these tools part of your workflow.

    I’ll also point you to a few learning resources along the way, so you can take this knowledge and start exploring the potential of this powerful approach to CSS development.

    What’s Wrong With Plain CSS?

    If you love CSS as much as I do, you have to know that you’re one of the very few of us out there. For me, the power and versatility of CSS is a delight, and there’s a physical thrill I get when I manage to solve a tricky cross-browser display issue or sidestep resource-intensive JavaScript routing with some elegant little CSS animation.

    But people who aren’t as enchanted with CSS as you and I have some legitimate complaints. For example, it can be difficult to keep track of the inheritance of properties across elements with differing weights and positions in a growing CSS codebase. There are no variables to support making a universal change that needs to be referenced in multiple places. And it’s often necessary to create redundant code that’s difficult to maintain just in order to make a design work consistently across different browsers.

    For me, the most elegant approach to dealing with problems like these and other similar ones was created by Hampton Catlin, and open-sourced so the entire community could help it grow. I’m talking about Sass, a preprocessor for CSS that lets you write clean, maintainable, structured code that generates efficient and useful CSS.

    And since Sass supports the ability to write new and original extensions, it’s much easier for developers to come up with their own enhancements. One of the ones I turn to first is a Sass library called Bourbon. While Sass provides a versatile tool set to precompile CSS, Bourbon builds on top of that with enhanced Sass functionality that makes it even faster and easier to write clean and compact code that’s easy to maintain and share.

    Using Sass

    There are several ways to get started with Sass. You can install the Ruby gem, use a development kit that includes Sass (like the Mac app, CodeKit, or take advantage of the LibSass library for native compilation performance in a language like Node or C.

    Once you have Sass installed, the basic workflow is to write your CSS using the Sass language, and then compile that into regular CSS that any browser can read and understand.

    Installing Sass

    The method you use to install Sass is a personal choice, and it will largely be based on your preferred development workflow and your overall skill level. Ruby is one of the most convenient ways to run Sass. I use a Mac, as I’m sure many front-end developers do, and that means I have Ruby pre-installed. So I’m going to assume you have Ruby installed and are running your commands in a terminal on your workstation. (There are excellent guides to installing and running Ruby in different environments and if you’re on Windows, you review this article to help get set up.)

    Once you’re in a terminal, and you’ve verified that you have a stable release of Ruby 1.9.3 or later installed, you can issue the following command to get the Sass gem installed:

    [code language="shell"]
    gem install sass

    Then you can make sure Sass is working by issuing a version check for Sass:

    [code language="shell"]
    sass -v

    This should show you that Sass is installed and running, and tell you what version you have. Anything higher than 3.3 should work just fine for this tutorial.

  7. Do You Make These 7 Agile Estimation Mistakes?

    A number of conceptual challenges can come up for teams when estimating stories. Sometimes these can lead to confusion about how agile works, and whether its actually delivering on what it promises.

    Being aware of these pitfalls, and having a clear answer to the questions they raise, can help keep the team on-track and keep observers from feeling disconnected.

    1. Measuring Productivity by Points

    Among the most common issues that cause confusion when explaining agile is the idea that the points of effort associated with a story represent the value of that story, either in terms of business value, or in terms of objective team productivity. That kind of misunderstanding can get in the way of effective estimating.

    A team cannot be compared with another by matching the points they have completed or their average velocity any more than they could be compared by looking at the size of their monitors.

  8. 3 Powerful Estimation Techniques for Agile Teams

    One of the key advantages of adopting an agile workflow is the ability of the team to estimate new work effectively.

    Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they’re going to approach stories, and how much effort each user story will take to complete.

    Once a team has been working together for a while, their ability to estimate new stories becomes much better. Teams with a history of past successes and failures can compare their velocity against point estimates that everyone can agree to, and as a result they can predict with reasonable accuracy how difficult it will be for them to complete a new story.

    But teams new to agile sometimes have difficulty figuring out how to estimate stories effectively.

    For some, the abstract and team-specific concept of points is difficult to grasp. For others, the soft relationship between point value and actual time spent working on a story can be distracting.

    Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.

    Here are a few techniques that help ease teams through this phase.

    These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.

  9. Using Regular Expressions to Check String Length

    Regular expressions are the ace up the sleeve of many of the most talented programmers out there. With a solid understanding of how regular expressions work, it’s sometimes possible to bypass a tangled mess of conditional logic and recursive function calls with a simple one-liner that just gets the job done much more efficiently. One […]

  10. Why Managers Make Terrible Scrum Masters

    Agile techniques such as scrum require the attention of an agile team leader or scrum master who can run the daily standups, maintain the velocity charts, and oversee the rituals such as sprint planning meetings, retrospectives and demos.

    Those duties generally belong to a member of the development team, and they do take time and attention. That means team members who take on these duties will be drawn away from their normal responsibilities.

    Because of this, in companies without dedicated scrum masters, a team’s manager may be tempted to take on the responsibilities.

    On the surface this may seem like a logical choice.

    The manager is the one person who should be most familiar with what everybody on the team is doing. A manager may appear to be in the best position to oversee the process and evaluate whether or not scrum is being followed. In fact, many of the responsibilities of a scrum master do fall upon management in a more traditional organization.

    But there is a basic conflict of interest between the duties of a manager and a scrum master.