Every year we donate a portion of profits to organizations and causes selected by the employees of Carbon Five. We neglected to update our site with the list for 2008 until today.
Personally, I am particularly psyched to be supporting the San Francisco Bike Kitchen in their move to a beautiful new space at 19th & Florida in the Mission. I have been volunteering as a mechanic with the Bike Kitchen for almost four years and have been continually impressed by the dedication and innovation of the all-volunteer staff and board. The bike racks at Carbon Five are full every day and the Bike Kitchen keeps many of us rolling smoothly to work.
Previously we discussed building an iPhone Unit Testing Toolkit. I wanted to reuse that work without having to repeat those configuration steps every time I started a new Xcode project. Xcode provides a number of templates or starting iPhone applications so I made my own versions which include all of the unit testing tools we rely on.
Continue reading ‘Custom Xcode Templates for iPhone Development’
Update: This code and documentation is now available on github: http://github.com/ndp/assert_changes/tree/master
The Problem
On our work on gobalto.com, we spend time to have good fixture data for our tests– data that can represent all the important application states that our tests require. As a result, our tests are very dependent on the data. It’s important that someone doesn’t inadvertantly change it in subtle ways. This has led us to write not only asserts at the end of tests, but pre-conditions as well. For example,
...
inotech = companies(:inotech)
assert inotech.services.public.include?(categories(:a))
assert inotech.services.public.include?(categories(:b))
assert inotech.services.public.include?(categories(:c))
post :edit_services_dialog, :id=>inotech.id,
:service_category_id=>categories(:a).id
inotech.reload
assert inotech.services.public.include?(categories(:a))
assert !inotech.services.public.include?(categories(:b))
assert !inotech.services.public.include?(categories(:c))Although the pre-conditions were introduced to guard against accidentally changing fixture data (or just to figure out what’s going on), we don’t necessarily delete them. They provide stronger tests. And in some ways, leaving in pre-conditions make the code more readable by providing documentation of your assumptions to the readers. The code above would be hard to follow without the clarifying pre-conditions. What do we expect to change and what stays the same?
Unfortunately all these asserts make the tests twice as long. And there’s a subtle readability problem: there’s no relationship between the corresponding pre- and post-conditions. In the example above, you have to scan carefully to see that the three assertions are repeated, but negated (b and c only). The reader must mentally put pieces together. And it’s not DRY. Using local variables doesn’t help much.
The Solution
I was inspired by a nice little test helper called assert_difference. It takes a string to evaluate and a block to execute. It’s useful for checking on state changes– especially database changes– during a test:
assert_difference('Company.count', -1) do Company.delete_one end
(Without this method, we rely on a count of all database records, or merely look for specific ones. The former approach leads to brittle tests, and the latter to incomplete assertions.)
A limitation of assert_difference is that it only deals with integers. What if it were generalized? Here goes:
i = true assert_changes 'i' => false do # read as: i changes to false i = false end
Continue reading ‘assert_changes and assert_no_changes in Ruby’
I grabbed Twitter search results for our #agileux20 hashtag so we don’t lose them later. Thanks everyone for your interest, comments and questions. Unlike Twitter search, these tweets are listed oldest to most recent so you can read them as a transcript of our panel.
if you want to tweet questions to the design vs dev agile panel at #w2e, use tag #agileux20 and i’ll as many as i can to the panel.
How are you defining "design"? Is physical co-location a requirement for success in agile desi? Is upfront design required? #agileux20
#agileux20 really interested in learning about user behavior testing …. how to figure out the impact of new design on existing community
Shout out to Maria Giudice from Hot Studio, now at the helm in Room 2005 on human-centered design #w2e #agileux20
Attending the human centered design meets agile development session #w2e #agileux20
http://twitpic.com/2q72j - Human-centered design meets agile development #w2e #agileux20
Tag #agileux20 for: Can’t we just all get along? Human-centered design meets agile development
http://twitpic.com/2q773 - Maria AKA Wonderwoman moderates #agileux20 #w20
#agileux20 Panel: @arenareed, Dave Shih, @asalant, @robsp, @mgiudice #web2expo
http://twitpic.com/2q7at - Maria with her whip at the ready #agileux20 #w2e
RT @moyalynne: http://twitpic.com/2q7at - Maria with her whip at the ready #agileux20 #w2e
http://twitpic.com/2q7gj - Agile Manifesto - Agile Values #w2e #agileux20
Work Utopia: Human centered design meets agile development; xp (extreme programming) #agileux20; seems logical. Let’s DO it!
@razasaeed #agileux20 did @robsp’s overview of aardvark’s research approach answer your question?
#agileux20 do you expose functional prototypes to users, mockups, alphas? What tools are use?, irise, others? How often do you engage users?
On Agile and Ux together — but "How realistic is it that user research actually happens early on?" - @mgiudice #agileux20 #w2e
http://www-users.cs.york.ac.uk/~pcairns/HCIDC/ArtefactPhilosophy.pdf. #agileux20
Clients might already have research they need? "I don’t feel like I’ve ever done enough user research" Arena Reed — #agileux20 #w2e
How much user research to do and when to do it as key question in human-centered design. #agileux20 #w2e
#agileux20 Curiuos about differences btwn web sites and web apps from a agile UX perspective
One thing that’s clear is that "design and engineering teams need to share knowledge during user research phase"– @mgiudice #agileux20 #w2e
Here’s a hypocritical question: can user research kill innovation? #agileux20 #w2e
A lot of great ideas wouldn’t exist if they were user validated (like twitter) so do you always follow the user results? #agileux20
It’s a great question #w2e #agileux20 How much design *should* be done up front?
No upfront design can be painful, and too much upfront design can be painful too — what’s the right amount? — Arena Reed #agileux20 #w2e
"Anything we’re immediately developing HAS to be fully designed" #agileux20 #w2e
Should the design phase have it’s own sprint including burndown? #agileux20
How many people out there are using agile practices for visual design? #agileux20 #w2e I work with @thegroop and they rock it.
What is an ideal ratio of product managers to developers in an agile process? #agileux20 #w2e
What flexibility should developers have in changing or improving the design in following implementation iteration? #agileux20
#agileux20 : You mentioned "getting everyone in one room" suggestions on this process with a global/virtual team?
Consultancies deal with a different issue, which is the need to document and deliver- the "do just enough" idea is difficult #w2e #agileux20
You can’t track design the way you track engineering. It stifles creativity. #agileux20 #w2e
If you’re a hardcore engineer passionate about social search & looking for a new pre-launch startup opp, ping me. #w2e. #agileux20
@AllanWolinski Designers on the panel use tracker for tasks but do not work within the scrum sprint/iteration #agileux20 #web2expo
"The goal is working software in users’ hands — everything that gets you there is disposable" - on only "just enough" docs #w2e #agileux20
What about for "lessons learned" and improving the process? What documentation does Agile preserve for that? #w2e #agileux20
@moyalynne #w2e #agileux20 sorry, didnt get your last question in. they’re moving pretty fast.
when they mention "track" the folks on the agile panel are referring to pivotaltracker (used for tracking stories) - #agileux20 #web2expo
RT @arnoland: User research can never kill innovation, stifle but never kill, for that you need an incompetent designer -;) #agileux20 #w2e
RT @arnoland: User research can never kill innovation, stifle but never kill, for that you need incompetent designer -;) #agileux20 #w2e
#agileux20 #w2e thanks for the great questions, & aplogogies i didn’t get to more of them. follow up w/ speakers contact info on last slide
@joshdamon They do not have a visual design so not sure .. especially when you need to roll out a new design and measure impact #agileux20
Maria Giudice from Hot Studio and I are following up our Core Conversation at SXSW last month on agile development and human-centered design with a panel Thursday at 11am at Web 2.0 Expo in San Francisco titled Can’t We Just All Get Along? Human-centered Design Meets Agile Development.
Our panel includes Arena Reed, Lead User Experience Designer at Grockit, Rob Spiro, co-founder of Aardvark and Dave Shih, Senior Visual Designer at Hot Studio.
At SXSW Maria and I realized how easy it is to talk about the challenges of coordinating design and development efforts since almost everyone involved in software development has experienced some pain around it. I’m excited about our panel for Web 2.0 Expo because I think we are going to better organize the discussion around identifying best practices. I am particularly inspired by the work of the Aardvark team who are intensely user-focused and test like crazy to validate their ideas and implementations while maintaining an agile software development process with frequent incremental releases.
You can follow our panel on Twitter with hashtag #agileux20 even if you are not at the conference. We welcome comments, questions and suggestions before, during and after.
Our client SmartyCard launched in early March at the DEMO conference picking up the People’s Choice Award. SmartyCard is a learning site that offers kids rewards for completing a variety of interactive learning games. Kids are able to ‘learn, earn and play’ grade-appropriate games while earning real and virtual rewards.
On those occasions, I supplement my list in Tracker with another technique for capturing user stories. It involves modeling using a UML IDE. Primarily, I use Activity Diagrams because they capture behavior using ‘actions’ and allow for flow. Because activity diagrams are essentially flow charts, they provide a simple comprehension mechanism for all customers regardless of their technical background. I usually display my desktop in the conference room using a projector and interactively add elements to the diagram as I receive customer input. For demonstrating modeling techniques, I will use a ‘Music Store’ web application as an example.
Summary of Steps:
- Create an Activity Diagram from a High-Level Functional Requirement.
- Capture Customer Input for Identified Functional Requirement.
- Model Flow for Activity, Link Actions with Diagram Elements.
- Aggregate Similar Actions to Separate Activity.
- Convert Activity Diagram into User Stories.
- Repeat Steps until all Functional Requirements are Exhausted.
Step 1: Create an Activity Diagram from a High-Level Functional Requirement
Start with a known high-level functional requirement and create an Activity diagram. When starting, I will identify a large chunk of functionality that I know to be required for the project and use that as a discussion point with the audience. For my sample Music Store project, I would choose ‘Browsing the Inventory’ as a large piece of functionality. At this point, the audience might begin to shout out other large pieces of functionality (i.e. ‘Customers can create accounts’, ‘Employees can add to inventory’). If this occurs, I like to create empty Activity diagrams named appropriately. These large pieces of functionality will eventually be decomposed into smaller, more manageable, Activities and Actions.
Step 2: Capture Customer Input for Identified Functional Requirement
Gather input from the audience regarding this Activity / functional requirement and capture pertinent information as Actions. Essentially, what you are trying to do here is decompose the larger ‘Browsing the Inventory’ functional requirement into smaller ones. Make an attempt to name each of the Actions with story-like syntax (i.e. ‘As a <role> I can <result> so that <benefit>’). The goal of this step is to create a catalog of smaller functional requirements so that you can start modeling flow.
Step 3: Model Flow for Activity, Link Actions with Diagram Elements
Start modeling flow for this Activity, linking Actions with other diagram elements. All Activities must have a start as well as an end point. I model my Activities so that my flow is complete. This ensures that all known paths have been captured. This step is crucial in capturing all known functionality for the high-level requirement.
Remember that this is an interactive step with the audience. The audience / customer will provide input as to the flow of the Activity from Action to Action.
Step 4: Aggregate Similar Actions to Separate Activity
If the diagram begins to flow outside of your viewable area, this is an indicator for breaking out one or more actions into a separate Activity. Several actions can be converted into one abstract action that encompasses all the functionality provided by all those actions. In the figure in step 3, the Action ‘Purchase an Item’, was created to represent another Activity diagram. The separate Activity diagram that I created was named ‘Purchasing an Item’ and contains the detailed flow for that functionality.
This step is reliant on the Tech Lead’s skill to identify similar areas of responsibility within the activity.
Step 5: Convert Activity Diagram into User Stories
After one Activity diagram is fairly complete, begin entering them into Tracker as Stories. Each Action should be converted into a user story using a consistent syntax (i.e. ‘As a <role> I can <result> so that <benefit>’).
Step 6: Repeat Steps until all Functional Requirements are Exhausted
Steps 1-5 must be repeated until all high-level functional requirements have been modeled as Activities during discussion. In the end, I will have a catalog of Activity diagrams. In the figure below, a Package Diagram displays all the Activity Diagrams that I have modeled. I like to use each of the Activities as a milestone during planning. This may or may not be ideal depending on how granular your functional requirements are.
Conclusion
There are many arguments against modeling in the agile communities, so it is important to view modeling as being supplemental to the process. In the end, our models are used to aid in the process of conveying and gathering information with the customer. Some other benefits include:
- The diagrams can serve as a documentation deliverable
- Interactive modeling along with the diagrams, which serve as a visual aid, improves customer comprehension of our software development process
- This is a great way to capture requirements when none exist
- The Activity diagram allows us to write stories in a format that follows an accompanied wireframe (if available)
- User roles can be added to Activity diagrams as swimlanes (partitions). This aids in separating functionality by use case
I get tired of hunting through a hierarchy of folders and files, from the views to the public folder, to locate a certain CSS or Javascript file. It’d be convenient to have them right with the markup, but embedding these definitions within your HTML markup is a bad idea for several reasons. For our current project, I proposed we put everything in the view directory so they are easy to find:
app/ views/ home/ index.html.rb index.css index.js
The convention is clear: to add page-specific CSS code, just create a new file with the same name as the view, in the same folder. Easy to add, edit and remove. The alternative (using the public folder), usually leads to a parallel hierarchy and the inconvenience of that.
I also thought, that this being Rails and all, the files should be included automatically. It turned out to be pretty easy. Continue reading ‘Convenient CSS and Javascript in Ruby on Rails’
![]()
Maria and I have already started our SXSW Core Conversation When Worlds Collide: Human Centered Design Meets Agile Development two weeks before the event in Austin. The Core Conversation format is a speaker or two in conversation with the audience. Below we respond to a few select questions.
About the Presenters
Maria Guidice is CEO and founder of Hot Studio, a human-centered design studio in San Francisco.
Alon Salant is a principal and founder of Carbon Five an agile software development firm also in San Francisco.
Our companies have worked together over the years on a number of successful projects. We find our collaboration continually challenged by the differing perspectives of designer, developer and client. We love working together and are always looking for ways to do it better.
We Want to Hear From You
Join us for this conversation in Austin Sunday, March 15, 3:30-4:30pm. If you can’t make it, we have created a Google Moderator series to solicit questions from you. Please vote for questions you like and/or add questions and topics that you think we should discuss. Alternately, ask questions as comments to this post. We want to hear from you.
Let’s Get Started
Why is the issue of waterfall vs. agile so emotional for design and engineering teams?
Alon: We all work hard to do the best work we can for our customers. Software developers have struggled for years with the mismatch between heavy-weight planning processes, the ideal world they are based on, and the messy work of getting software built in the real world. Agile software processes provide an approach that deals very well with the real world while retaining strong professional rigor.
Committed agilists bristle at approaches that do too much planning for too far in the future. The further out you plan the more inherent uncertainty there is and the greater the chance that you are wasting energy on speculation.
For designers I think you can flip this argument around. If you start building something without knowing what you are building there’s a good chance you build the wrong thing and have wasted all the time and effort you put in to it.
Obviously there’s a middle ground somewhere. It turns out to be surprisingly hard to find.
Maria: I think the reason that this issue is so emotional goes to the very core of the fundamental difference in the way designers and engineers think about design.
The waterfall process affords designers the time and space to learn about the problem and craft a solution based on insight from understanding human needs, wants and desires. They then can craft a plan of action based upon big-picture thinking and strategic insight. From there they can be specific about details and functionality based on how the system works contextually.
The agile process oftentimes does not afford designers the time to think and requires them to design details out of context. This way of working puts them at great unease and anxiety that they are designing things based on hunches rather than validated user research.
Engineers, however, feel very comfortable working at a detail level that can be changed (theoretically) later on and can build towards a functional product sooner rather than later. Engineers may not understand the need or value to spend the time upfront—”why not jump in early if you have the freedom to change your mind?”
Think of the two processes like carving in marble vs. building in clay. It can be very difficult to switch design mediums they have worked on their entire professional life.
What is your greatest satisfaction when working with designers?
Alon: Designers have the gift of being able to represent ideas and solutions visually, in a form that all stakeholders in a project can understand and respond to. A designer can engage business owners and developers in a conversation about product requirements, priorities and potential solutions then turn that into a visual representation of one or more solutions. The visuals create a level playing field and focus the attention of all participants in a project. I love the role of designer as facilitator.
What is your greatest satisfaction when working with engineers?
Maria: We look to work with engineers that consider themselves equal contributors to the design process. Hot Studio is lucky to work with the folks at Carbon Five for this very reason. Too often designers view engineers as builders of “their product” and they miss the value of thinking about a design problem from an entirely different mindset. Great engineers understand the value of human-centered design and are active participants and contributors throughout the design process. Great engineers bring to the table that unique perspective that does not focus on limitation, but one of unique possibility.
What is your biggest point of frustration when working with designers?
Alon: Many designers, particularly user experience designers, feel they need to understand a problem in both depth and breadth before they can create meaningful solutions. Even when a project schedule and budget allow for up front research too often it is not enough for the designer and they feel they are working with incomplete information.
Projects can rarely afford exhaustive up front research and I get frustrated when designers use this as an excuse instead of coming up with an alternative approach.
I would like to find a design approach that could use some research up front to set a strategic direction and then break up a large problem into smaller problems to be tackled incrementally. Ongoing research could continue to be a part of the design process, conducted incrementally as the next problem to solve comes in to focus.
What is your biggest point of frustration when working with engineers?
Maria: I have worked with many engineering teams over the years, and like designers, they can come in many different flavors. I get frustrated when engineers focus on limitations, not possibility. When design thinking becomes limited to meet a tight budget or the need to jam as many “features” into a product based upon a set timeline, you run the risk of prohibiting “out of the box thinking” that can have an adverse effect on maximum customer experience. What some engineers may think the experience is “good enough”, designers may conclude that “no it isn’t”. This is a big point of frustration for designers regardless of the problem they are trying to solve or the process they are working within.
What will people come away with after attending our core conversation at SXSW on March 15th?
Alon: Our conversation will give people insight into issues in the collaboration of designers and developers and ideas about how to work together better. It is an opportunity for attendees to learn more about human centered design and agile software development and to challenge our ideas on those subjects.
Maria: I think people will come away with thinking that one size does not fit all. Follow a process, whether it’s waterfall, agile or a hybrid between the two, based on the type of project, the team dynamics, and the client’s need.
Can we all get along?
Alon: Sure. But it may be harder than we think. For this collaboration to be truly successful designers and developers need to better understand each others’ priorities and fears. It’s too easy to sit back in your own world view and say, “They don’t get it. If they did they’d do things my way.”
Maria: Absolutely. It really comes down to respect, empathy, and good communication from the client, to the designers, to the engineers. To quote the critically acclaimed “High School Musical 2″ film—”We are all in this together!”
Together, as design collaborators, we can produce great things together and hopefully, have a positive impact in people’s lives.







