Why we don’t use OOCSS (but we should)

Saturday, May 25, 2013

I recently had the opportunity to pair with Nicole Sullivan (of OOCSS fame) for a few days on my current project. I learned as much as I could about css components in the three days available and then rebuilt the most painful part of our UI with components over the next week. I learned two broad things from this experience. First, css components are amazing. I didn’t realize how much pain I had in css until I saw how much easier it was with components. We should definitely use them. Second, css components feel weird in the normal web development world. There are good reasons we haven’t used them at Pivotal. It just turns out the reasons for not using them aren’t good enough.

I may write another post on why OOCSS is so amazing, but I think the more interesting post are the reasons to resist OOCSS. Hopefully someone just trying it out will be pre-warned about these pain points and will be able to make a smoother transition.

1. HTML and CSS are just not as important as the server code or javascript for a web developer. I spend most of my time in ruby or javascript and am always looking for ways to make coding those things more sustainable. I don’t spend very much time in HTML or CSS, so there isn’t the same drive to improve them. I need big wins in CSS coding to justify changing anything. Luckily, OOCSS fits the bill.

2. You can’t test css. Agile development relies heavily on the ability to refactor, which relies heavily on test coverage. Say you had a page with many buttons, but the client only tells you about a new one every week. With each new button, you add some html and css, and then some javascript click handlers. After enough buttons, you refactor the javascript to reflect your new understanding of the page. You can do this safely with enough test coverage, but how do you refactor the html/css without breaking something? A style guide goes a long way here, but it’s not the same as test coverage. In my refactor, I just had to spend the time comparing the look of the refactored css with old versions. Mildly painful, but still worth it.

3. The design patterns of rails are simply different than OOCSS. If I want a page with a list of users, I will make a users_controller.rb with an index method. I will make a user_list.js file for client interaction (assuming it is complicated enough to need one). I also want to make a user_list.css file. Unfortunately, almost anything I would put in the user_list.css file is bad for OOCSS. I need a lists css file which doesn’t know anything about users. In fact, none of my css files should know anything about users if I can avoid it. This isn’t hard to do once you realize it is important, but it never occurred to me until Nicole pointed it out.

4. Javasript class names are usually semantic. OOCSS class names are not. They should not depend on the content in them, and might have absolutely nothing to do with the underlying business logic If I have a list of users in my page, I naturally want to make a ul with a class like “user_list”. In OOCSS most of the list styling for a user list should come from some generic class like ‘list_vertical’. You don’t want the ‘user_list’ class unless the javascript needs it. This felt unnatural for a few days, but I eventually got used to it.

5. There is a lot of extra HTML in the early stages of an OOCSS refactor. I ended up creating extra uls and divs in the weirdest spots just to get things to layout correctly. And then there are all the extra classes. You aren’t supposed to re-use javascript selectors in css, so you need to write new selectors for that. You also shouldn’t use parent classes in your selector, so html that used to look like

html:
<div class="error">  
    Something went wrong!
    <button>Try again</button>
</div>

css:
.error { background-color: red; }
.error button { color: white; }
now needs to look like

<div class="error"> 
    Something went wrong!
    <button class=button_error">Try again</button>
</div>

.error {background-color: red;}
.button_error {color: white;}

You still need the “error” class to style the error div so the “button_error” class is just thrown on top. The whole situation is made worse by html that is full of copy-paste. In my refactor, there was a particular button type that was created over 100 times in our html and I wanted to add an OOCSS class to it. We pulled it into a partial to solve the problem, but too much of this and it starts to feel like we need to refactor our html templating before we can refactor OOCSS. I’ve been assured that a full OOCSS refactor actually results in 20-50% less html depending on the project. The ‘extra html’ phase is only when you have added the OOCSS html but haven’t added enough that you can remove your old html scaffolding. Even during this phase, the extra html isn’t so bad because at least you have a lot less css.

6. Components only work if you see patterns in layout that repeat themselves. Many of the components I am now using weren’t obvious to me as patterns worth extracting. I didn’t start seeing them in the site until I became familiar with the common OOCSS components. You do actually have to put effort into this. The other failure mode here is if your website just doesn’t have repeatable patterns due to inconsistent design. Now you need to add convincing your client to streamline the design to your list of tasks. On the plus side, making css components is a very good way to show your client the inconsistencies in the design and should result in a better site.

None of the difficulties listed above are deal-breakers, but they do add up to a lot of headwinds in moving to OOCSS. Even with those headwinds, the transition has already been an easy win for my current project and I believe most sites would find the same thing.

Design Pairing: Can two designers really share a screen?

Nina Mehta

Friday, May 24, 2013

This post is pair-authored by David Friermor and Nina Mehta

Traditionally, pairing has benefited both pivots and clients improving productivity and quality of output. We want to see if design pairing is a way to move creative, collaborative work forward. We define design pairing as when two designers, work with two mice, two keywords, two displays but only working off one computer. We paired all this week and want to share our reflections with the community.

This week we did remote user testing, script writing, card sorting, sketching, wireframing prototyping and some visual design. Because we worked in a pair, we had more fruitful research findings and came to a better site architecture for our current project.

What’s awesome

We found that the quality of what we produced was higher and done faster than if we worked in silos and came together just for reviews or critiques. By working in pairs, we were able to share processes, skills and techniques to find the best answers of the design problems we were facing.

Pairing also allowed us to put our work through a rigorous process and have focused discussions as decisions were made. Real-time critique makes our work better and let us execute and build upon ideas as we were having them.

What’s hard

Design etiquette and pairing etiquette is already difficult; combining the two is no walk in the park. Letting go of control is hard. Letting go of your keyboard, your ideas, and your chance to say something is all hard. And especially when you don’t want to.

Design is traditionally an internal process; it’s difficult to discuss and explain every thought. We are trained to defend our ideas and refine a thought before sharing it. Getting into each others’ minds at first was uncomfortable and made us feel vulnerable. Once we got over the first hurdle teaching each other what we knew became fun and made our work better.

Well, now what?

We only paired for a week and feel like we’re stepping into somewhat uncharted territory. We recognize that design pairing is not feasible for every project, however we want to see what this can do for other product designers.

Do you have experience design pairng? Tell us about your experience.

Finding the middle for designers and developers

Nina Mehta

Wednesday, May 22, 2013

Oh the age-old ‘should designers code?’ debate again. Nope! I pushed the matter further last night at Pivotal’s Extreme Roundtable meetup in LA. I asked, ‘how involved should designers get into code?’ and ‘Should developers design?’ In a room of 7 developers, the latter surprisingly got the most votes.

It all comes down to finding the middle and meeting there. It’s challenging for developers when a designer is thinking too high level in abstractions or too low at implementation details. Having conversations at the wireframe level, the middle, lets both parties have fluid discussions about product and implementation. It also gives the opportunity to try something out before going too far down a path that has a dead end.

When designers get too far in the ahead, the product owner gets too committed and excited about an idea that’s still just an idea. If they devs aren’t involved early in the process, product owners are sometimes “so juiced” on the idea that they’re disappointed or frustrated when implementation is expensive or ends up not being a good direction. It’s important for the three teams: design, development and product to be exploring ideas and communicating throughout the process.

However, designers who know a lot about code and implementation can be a dangerous constraint. It’s important for designers to understand how code works, but not be a barrier in ideation and generation phases. Let us not forget blue-sky design. One developer said, “sometimes they come up with really expensive ideas that are hard to implement, but it’s worth it because the design and user experience ends up being excellent!”

It’s a toss-up about whether or not developers should design or make product decisions. In some regards, they leave that up to the designers, which can be frustrating if the designer is blocking and not able to make quick decisions during development time.

Developers do have a lot of experience with implementation and should speak up what they’ve built before. It is ok for them to talk about where a design path may lead, because it doesn’t always lead to fairy tale ending. Devs should feel comfortable telling designers, “I know your expectations for this layout [or interaction]. It doesn’t play out how you think it it will. It doesn’t usually go the way you want.” They should of course propose some alternatives or explain which part doesn’t work. It can be frustrating for a designer to hear that, but that’s why it’s so important to start conversations at the wireframe level.

The developers last night said they like the idea of designers coding–if their code is good enough. It’s more important designers understand how code works to inform discussions and decisions.

What do you think?

Showing and hiding conditional HTML without Javascript

Stephan Hagemann

Tuesday, May 21, 2013

Have you ever filled out an address form that had a checkbox for “my shipping address differs from my mailing address”? When you click that box a conditional form part gets revealed that allows you to enter another address. We had to build something very similar the other day and stumbled on a neat way to make the conditional part show and hide with CSS only.
Continue reading →

Finding Pivotal

Matthew Parker

Monday, May 20, 2013

The year is 2005. I’m one year out of school, and a year into a job doing PHP web development at a small development firm in Dallas. A co-worker tells me jokingly about extreme programming. He laughs about the absurdity of pair programming and writing tests. Another developer goes rogue and develops an application in something called “Ruby on Rails.” He’s learning the framework at the same time he’s developing the application. I boast that I could have done it in half the time in PHP. That developer takes a job for a company in Seattle doing Ruby on Rails. I spend another frustating year at the company in Dallas.

Fast forward four years to 2009. I’m now living in Manhattan. Burned out on PHP, I’ve spent the last year doing free-lance Ruby on Rails development. I love it. It’s everything I wanted out of a language and framework. It solves all of the common, tedious problems that I faced developing in PHP, and lets me focus on developing my applications.

I land a job at a giant multi-national corporation. The team I’m working with is agile. They hold standups. They have a certified scrum master. They do two week iterations (on projects with fixed scope and hard deadlines). They estimate stories (in hours) (that they write themselves). They write tests (sometimes) (after they write their production code).

It was the best thing that had ever happened to me. And it was hard. And it was painful. We attempted to be agile within an organization of six-sigma blackbelts that would spend 18 months defining a process for defining processes. We didn’t know what we were doing half the time. We got a lot of stuff wrong. But we cared. And we learned. And we got better.

Fast forward three years. I’m still working for that giant company. I get an email from Pivotal Labs. A co-worker warns me, “You know they pair all the time.” I’m a little frightened. I go in for a day-long pairing interview. It’s amazing. I learn more in that one day than I had learned in the last year of work. I pair with developers smarter than me, better than me, and more experienced than me. I take the job.

Every day at Pivotal is like that first day, but even better. I learn something new every single day. I work with other engineers absolutely committed to developing great code. We give new meaning to the word “consultant”, giving our clients not just advice, but pairing with them to act on that advice (and course-correcting when things go wrong). We pair program. We test drive. We collaborate on story specification. We start each week looking at our priorities and estimating our stories. We end each week reflecting in a retrospective, talking about what’s working, what’s not, and what we should do about it. We take breaks throughout the day. We play ping-pong. We’re relentless about self-improvement, team-improvement, project-improvement, and company-improvement. And I’ve never been happier. I’ve never had the privilege of working with such a talented, passionate group of people.

We want to change the way the world develops software. You can too. Do the right thing. Do what works. Be kind.

Simple Test Parallelization

Hunter Gillane

Monday, May 20, 2013

Let’s look at a simple approach to parallelizing a test suite for a Ruby app. Parallelizing your specs can be a good strategy to get a speedup on an existing slow suite. It can also be employed early on a greenfield project as part of a commitment to fast tests. The same caveats that Andrew mentions in that article post here as well, namely that parallelization might mask more important design changes you need to make in you suite.

While you could use a gem like parallel_tests, let’s look at what it would take to achieve this without needing to pull in another dependency.

The only requirement to employ this approach is that the parts of your build that you want to parallelize do not share a database, or if they do, that it will not cause test pollution if your specs run at the same time. These parallelizable portions of your build could be Rails engines, a library in lib, an unbuilt gem, or any other isolated piece of your app. If your app doesn’t meet that requirement, something like parallel_tests will likely be more useful.

Let’s assume that you are using engines to organize functionality in your app. In this case you likely are already using a separate database for each engine’s test suite, so let’s use that as a basis for our example. Assuming that you have two engines (engine1 and engine2) and they are both in the engines directory, you could write a rake task that parallelizes your build that looks something like this:


task :build do
  build_pids = []

  %w{engine1 engine2}.each do |engine_name|
    build_pids << fork { exec "cd engines/#{engine_name} && rspec spec" }
  end

  trap(:INT) do
    build_pids.each do |pid|
      begin
        Process.kill(:INT, pid)
      rescue Errno::ESRCH
      end
    end
  end

  Process.waitall.each do |pid, status|
    unless status.success?
      puts "Build failed"
      exit 1
    end
  end

  puts "Build successful"
  exit 0
end

This rake task does three things:

Uses fork+exec to kick off child processes to run each engine’s build
Collects the child processes after they have completed and exits non-zero if any of the child build processes were unsuccessful
Captures INT so that all child build processes will be killed when you Ctrl-C in the terminal

The output can be ugly but may be worth the time savings, especially if you only are going to be running this task as a last check before CI.

Is there something funny about your Standup?

Graham Siener

Monday, May 20, 2013

Agilish

Software development teams that aim to be more “Agile” often pick and choose the pieces of an agile methodology that suit them. For some reason standup is usually picked first, way before addressing their waterfall ways. I guess it’s because it’s hard to do “retrospective” but easy to stand up during a meeting (despite teams that sit through their standup).

I’m a big fan of standups but have also witnessed ones that are poorly executed or even detrimental. A traditional standup is a five to fifteen minute meeting where each team member stands together and answers three fundamental questions:

What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress (blockers)?

A standup is not:

A status report for your managers
The forum for discussing details at length
A replacement for healthy and timely communication with your product team
A way to trick developers into coming in early

Walking the Wall

The intent of standup is to share work in progress and highlight blockers — why not use the tool where you manage your agile development process? This is typically referred to as “Walking the Wall,” and in my opinion creates a quicker and healthier conversation. Here’s how:

Open Pivotal Tracker (or your agile tracker of choice) on a screen that’s easily viewed by the team. Standup stations work well for this, otherwise you can huddle around the monitor with the most space. Close the Icebox and zoom in on Current.

Step through each story in the Accept/Reject state. Is it clear how a story should be accepted? Is it clear [for larger teams] who is doing the acceptance for a story? Side note for story requesters — do your best to accept stories right away. Nothing is worse for a developer than seeing a rejection at noon for a story that was delivered yesterday.

Moving onto the first story in progress, let the story owner describe the work and give a gut check on how it’s progressing. This is a great opportunity to raise concerns about an estimate, e.g., “This was pointed as a 2 but we had to do a lot of refactoring of the css. We’ve probably got another day of refactoring before we deliver.” Context is important, and highlighting this discrepancy gives the PM a chance to course correct if need be.

Once you’ve covered WIP, move on to the next set of stories in the Backlog. If any have blockers like a “needs-discussion” label, drill into the detail and identify if you can resolve them on the spot. If something needs design/assets, hopefully your designer (along with the rest of the core Product team) is there to confirm that they’ll upload the right files, etc.

Lastly, work out your pairs for the day and cover any housekeeping (“we’ll be reticulating the spines at 3pm, no pushing commits”)

If some important topic comes up and can’t be resolved within fifteen minutes, schedule a follow-up meeting with the people needed to resolve the issue. You don’t get points for dragging out a standup until every problem has been solved!

This is the format for standup that I default to now. I encourage you to give it a try if you’re finding standups have lost their value, or if you don’t think product stakeholders are in sync with the development process. As always, ask your doctor if continuous improvement is right for your team.

Debugging in RubyMine

Jared Carroll

Monday, May 20, 2013

Before using RubyMine, my debugging workflow went something like this:

Why isn’t this test passing?. It should’ve passed. Let me add a few Kernel#puts calls to see what’s going on. Hmmm, ok, it’s still failing. I’m going to need some more output. Man, these tests take forever to run. Syntax error?!. Ugh, typo…

Debugging like this isn’t fun; especially when pairing. Fortunately, RubyMine can help. RubyMine includes a standard debugger that has minimal setup and works out of the box. I still don’t enjoy debugging, but RubyMine has made it much less painful. In this post, we’ll look at debugging in RubyMine on OS X.

Setting Breakpoints

Add or remove breakpoints with command + F8.

View existing breakpoints with command + shift + F8.

Starting the Debugger

Debug the current program with control + shift + D. This will automatically open the Debug tool window (command + 5).

Use control + D to re-run the last debug session. View recent debug sessions with control + alt/option + D.

Examining a Program

Examine variables in the Debug tool window’s variables pane.

Use command + N in the Debug tool window’s Watches pane to watch a specific variable. backspace will delete a watch.

Use alt/option + F8 to evaluate arbitrary expressions. control + space triggers autocompletion.

Instead of using the Debug tool window, examine a variable inline by placing your cursor on it and pressing command + alt/option + F8.

Stepping through a Program

Step into a method with F7. Step over a method with F8. Step out of a method with shift + F8.

Use your cursor as a temporary breakpoint with alt/option + F9. Continue your debug session with F9.

Stop #puts’ing

If you’re using an IDE, take time to learn its debugger. Don’t litter your code with Kernel#puts and friends. Instead, set a breakpoint, start the debugger, examine some objects, and slowly step through your problems.

A Responsible Recipe for the Fewest Possible Meetings

Jonathan Berger

Monday, May 20, 2013

Meetings are crucial to healthy team communication. But they’re also opportunities for waste, occasionally dull, and always expensive. Every team is different, but continuing the theme of “Convention over configuration for process”, I’ve found the following structure keeps meetings to ~7.5% of your week. This minimizes waste, maximizes making-time, and makes for a nice scheduling default for projects.

1. Daily Standup

5x weekly, 10 minutes each

Standup is a short, team-wide orientation meeting. Each morning, the team meets for a the Team Stand-Up meeting. As it’s name implies, everyone should be standing up—even if they’re remote and parked behind a screen. Meetings tend to run short when everyone’s on their feet, and there isn’t much to cover anyway, just three canonical questions:

What did you do yesterday?
What are you doing today?
Are you blocked on anything?

Since the team is pairing, most of the time the second person will say “pass” since their pair already mentioned the stories they worked on, the issues they had, and what they’re doing next: sticking together or seeking a new pairing partner.

2. Iteration Planning Meeting (“IPM”)

1x weekly, 60 minutes each

The IPM is a weekly tactical planning meeting. It’s aim is to ensure that the backlog is in good shape, and that all the team members have a shared understanding of what the stories mean. The product manager leads the meeting by reviewing the backlog. Each story should be reviewed; questions can be answered, clarifications can be issued, and developers can estimate the stories. Ideally, the meeting is on Monday or Tuesday and the team will get through the current iteration’s undone stories and a healthy chunk of next iteration’s stories. On some teams, it helps to take an hour before the IPM to groom the backlog, prioritize, and flesh out poorly-worded stories in a pre-IPM meeting with a small group (usually the Product Owner and a single developer).

3. Friday Afternoon Meeting

1x weekly, 60 minutes each

A useful pattern on recent projects has been to block out an hour Friday afternoon and rotate between three meetings: the Team Retro, the Tech Retro, and the Release Planning. It’s nice to have a regular time, and every-three-weeks is about the right frequency for each of these.

Week 1: Team Retro

The Team Retro is a chance for the day-to-day members of the team to reflect on how things are going, celebrate successes, voice frustrations, and suggest Action Items. While there are plenty of variations, the classic Retro format is to throw three columns on a whiteboard:

“Smileys”, or things that are going well, represented by the expected emoticon :-)
“Frownies”, or things that are going poorly, represented by :-(
“Mehs”, or things that don’t fit cleanly in either category, but bear mentioning :-\

After ~25m of going around the room and throwing out Smileys, Frownies, and Meh’s, the team might spend a few minutes identifying items which have a common theme, and then spend the rest of the time suggesting action items, either for each item (starting with the Frownies) or, if time is short, on a theme-by-theme basis. The action items are recorded and assigned to individuals, and their progress is followed (often at the start of the next retro). For more about Team Retros, see 7 Best Practices for Facilitating Agile Retrospectives.

Week 2: Tech Retro

A Tech Retro is for and by developers. While pair-programming is essentially continuous code review, it can still be useful to take some time to step back and look at the codebase. Tech Retros often take the traditional “Smilely / Frownie / Meh” format, but focus exclusively on the codebase. This is a great time to talk about modeling decisions and suggest refactors. Often the action items resulting from tech retros are a long list of chores. Try to keep each one to a manageable size, and make sure at least a few of them make it into the backlog for the next iteration.

Week 3: Release Planning

“Release Planning” means different things to different Agilists, but in this context it’s a loose title for a long-range planning meeting. While the IPM is a short-term tactical meeting, it’s important to occasionally step back and look at the big picture. What are the product’s medium- and long-term goals? Are we on track? What should our next milestone be? The Release Planning should be attended by the whole team, and by the stakeholders like clients and CEOs who may not be part of the day-to-day workings of the team. It’s a chance to review epic story tracks, dates and deadlines, and to make sure that everyone has a shared vision of where the team is going—and that it’s a place worth going to.

Why Meetings Matter

Communication is crucial, but so striking a balance between waste and on keeping everyone on the same page. I’ve found that teams which hew to this schedule tend to have a healthy rhythm. While circumstances occasionally require additional meetings, especially on the part of the Product Owner or the outward-facing members of the team, this structure is sufficient to maintain healthy intra-team communication without taking developers away from code any more than necessary.

Do you have another default meeting structure that you like? Let’s hear about it in the comments!

Put the User in User Stories

Trace Wax

Monday, May 20, 2013

I’ve often been in situations where people see user stories in Pivotal Tracker as just a punch list of to-dos, line items for snippets of code we can write that does one little thing in a product owner’s head. Even that much is useful for its prioritization and clarity, but thanks to a great chat last week with Lean User Experience wizard Josh Wexler, I’ve found myself paying closer attention to the reason they’re called User Stories in the first place: the users.

Complicated business logic becomes much easier to grok when you have a clear scenario in mind for the person who’s using it. I was recently working on a piece of particularly thorny logic with a new client developer for Case Commons. It had to do with subtle requirements for when and how to get permission to update a foster family’s license. We read and reread the story and the explanation, but it was hard to communicate why we were doing the thing we needed to do. We were talking in circles, and as soon as that happened, we knew we were doing it wrong.

So I pulled out the blog post I wrote a month ago, and it turned out that my friend’s family and newly adopted children were in an almost identical scenario to the one we were working on. I pulled up pictures of my friends and their adopted kids to show to the guy I was pairing with, and described the social worker, Tania, who had connected them with their new family. From then on, it wasn’t some abstract user we were talking about, it was Tania. My pair and I discussed what would happen if my friends became able to adopt more kids, the process Tania would have to go through to make that happen, and where that information would go on the physical, printed foster family license we were implementing. Having faces and names to go with our code made all the pieces click together, when we see as the story title in tracker: “Foster Family Licensing worker sees checklist only if capacity has changed”

I’m looking forward to putting more users into more user stories to make them come to life. When each story is complete, what new awesome thing will that person be able to do, and what need of theirs will it fulfill?