Archive for the ‘Fog Creek’ Category

How to Get Started –and Stick with– Usability Testing

October 27th, 2014 by Gareth Wilson

As you’re working on a piece of software, you get to know it well. Perhaps too well. How to complete common actions become so obvious to you that you don’t need to think about them any more. This isn’t the case though when someone new comes to use your product. So getting your product in to the hands of users to test is a key step in its development. But of course, you already know this. Almost everybody does. Yet few people get around to actually doing it, and those that do, often stop after an initial release or phase.

Check out the video below featuring usability expert and author of “Don’t Make Me Think”, Steve Krug. Then read on for tips to help you get started, and stick with, usability testing.

Usability Testing doesn’t have to be complicated

Keep it simple
Usability testing doesn’t have to be complicated. Upon hearing the term ‘usability testing’, you might begin to imagine a testing lab, with cameras setup to film eyes, face, clicks and the screen. But it doesn’t need to be like this. All you really need is to find someone, provide something to test and a place to do it.

Take anyone you can get
Test participants don’t need to be familiar with your product. They don’t even have to be from your target audience. So grab a colleague (in our video we roped-in our Office Manager), a friend or anyone else who is around.

You don’t need hordes of people either. In fact, there’s little benefit in testing with more than 5 people.

Test early
You don’t need to have built something to begin user testing. Some sketches, linked screenshots or a simple prototype will do. The earlier you start the better, so you can avoid building unnecessary stuff later. A paper prototype can be enough to begin and start getting useful feedback.

Don’t get caught up with design preferences and feature requests
Your testers come with pre-conceived ideas of what’s expected of them. Most common is the idea that you’re after design feedback, in particular colors. Layout and design issues are important, but things like color are rarely your major problem. Unless people have a strong reaction (using words like “puke”), it’s often safe to ignore such feedback. Same goes with feature requests. You will already have loads of your own. So unless their idea immediately makes sense to all, you can skip these too.

Start with a few theories
Generate a few theories about why something important is happening. Such as why users aren’t converting, not using a particular feature or how they might complete a particular task. Think of a scenario to test this, and then run that test. After each test, debrief – discuss amongst you what you observed and why that might be.

Test once a month
Once you have carried out a test, make some changes, create more theories and set about testing them too. It doesn’t need to be too often – just one morning, once a month. This will provide a constant flow of feedback that will keep you on top of your major issues.

Once you’re in to it, use tools to help
There’s a bunch of useful tools which can help you with usability testing. Use Five Second Test to get quick feedback on UI, web pages and sketches. InVision for creating prototypes. LookBack (mobile) and SilverbackApp (desktop) to get in-app user-feedback.

If you try out these tips then there’s really no barrier to you starting and sticking with usability testing. Don’t forget to check out the video above to hear more on usability testing from Steve Krug and some of the Creekers.

7 Ways to Get More Out of Beta Testing

October 23rd, 2014 by Gareth Wilson

The weird and wonderful bugs that get thrown up when real users first start using your code never ceases to amaze. There’s always some odd edge case that had been overlooked, despite you having thought about little else for several weeks. We’ve been through this many times whilst developing FogBugz, Kiln and Trello. Beta testing is an important stage in the testing process. To learn a little about them check out the following video, then read on for our key tips:



Here’s 7 things you can do to get the most out of our your beta tests.

1. Ask for a commitment to provide feedback
Response rates will be higher if you ask your beta testers upfront to commit to providing feedback. This doesn’t have to be formal, just part of an application form. But having agreed to it, people are more likely to follow through.

2. Do not release with known bugs
Most beta testers will only provide feedback once. So you don’t want to burn any tester to just hear about known issues.

3. Allow enough time
Use the following as a rough guide. For a major development effort, say about a year’s work, then you’ll want 10-12 weeks for beta testing. Decrease as necessary – so if it took a month to develop, then around a week will suffice.

4. Be feature complete
Only beta test when you’re feature complete. Adding in things as you go sets you back to the start. Otherwise, it just means the new code and its impact on existing functionality isn’t as well tested as the rest. Something you’ll regret later.

5. Make it easy to get in touch
You want to make it as easy as possible for your beta testers to provide feedback, so give them direct emails and offer to jump on a Hangout/Skype if they’d prefer.

6. Remind, but don’t annoy
Whilst your product might be front and center for you, it’s not going to be that way for your beta testers. You’ll want to remind them along the way. But don’t over do it, they’re helping you out so you don’t want to annoy them with too many emails.

7. Don’t forget to provide feedback
Make sure during and after the test that you send them updates about how you are putting their feedback to use. People like to hear that their time wasn’t wasted. And don’t be tight with the swag – a free t-shirt can do wonders!

To learn more about beta testing be sure to check out the video above.

Announcing The Fog Creek Fellowship

July 21st, 2014 by Elizabeth Hall

The tech industry has a problem and Fog Creek shares it. Our small thirty-nine person company has eleven developers — all of them male — and only 14% of the technical applicants we have spoken to in the last six months have been women. We have extremely talented women working in various roles such as quality assurance, scrum master, finance, recruiting, and office management but no developers. We’re proud to have had (and currently have) truly amazing female developer interns. Their contributions to the team and company at large are apparent, but alas, we have none working with us full-time.

Everyone here at Fog Creek wants to help reverse this gender disparity. In the past, we’ve focused on our intern pipeline by recruiting heavily from schools with high percentages of female students. We’ve hosted and sponsored hackathons and events with a focus on women in tech. We provide continuing education programs for female employees who want to learn how to code. These efforts have helped some, but it’s not enough.

We want to do more. We need to do more. We will do more.

As part of a larger solution we’ve joined forces with our neighbor, The Flatiron School to create The Fog Creek Fellowship. The Flatiron School has an unprecedented commitment to diversity, training women and underrepresented groups through partnerships with government and self-funded scholarships. Their highly selective admissions process, their focus on incredible teachers and great curriculum, and their dedication to the programming community, have led to an exceptional track record of helping alumni launch programming careers with great companies. Their passion for providing women the skills they need to succeed in tech is contagious — making them the obvious choice for our partnership.

Fog Creek wants to keep The Flatiron School’s positive momentum going. A select group of female Flatiron School graduates will join us for a two month program where they’ll be paired with a Fog Creek or Trello mentor. The program kicks off with brainstorming breakfast where fellows arrive with three project ideas. Once they flesh out the details with their mentors they’ll begin working right away. Throughout the program they’ll also undergo technical interview training from our developers.

Fellows will experience what it’s like to work at a company that values developers. They’ll each have access to their own height adjustable desk, Aeron chair and all the snacks one can imagine.

Fellows will receive interview training from their mentors and be provided with immediate technical feedback, which is extremely rare in an interview setting. Our developers undergo months-long recruiting training and have conducted hundreds of coding phone and in-person interviews. They have priceless information to share with our fellows.

Fog Creek values the camaraderie and closeness that eating lunch together provides. Every day, fellows will either join the Fog Creek and Trello employees for a catered lunch or have a special 1:1 lunch with their mentors. Participating in these conversations, or just listening in, is a great way to dive into the tech community and continue learning.

Additionally, all fellows will have 1:1 pair programming sessions with their mentors. Fog Creek currently has a 0.4% acceptance rate for full-time developers; The fellows will be working with the best in the industry.

The Fog Creek Fellowship provides women, who have just learned a new skill-set and are eager to start their career in tech, the tools they need to get their first programing job. If we can help fellows prepare for coding interviews, offer assistance comparing offer packages, build confidence, and help create a long-lasting professional relationships with their mentors then we’ve done our job. We want to be a resource long past the program’s end date.

We are beyond excited to start this new endeavor and we hope it brings change to not just Fog Creek but to the tech community at large.

The Fog Creek Fellowship is only the beginning though; we know we have more to do. We are currently working with other amazing organizations in the industry to help all underrepresented groups in tech. Future exciting announcements to come!

* * *

Do you know of other organizations, schools, or people advocating for underrepresented groups in tech? I’d love to learn more, tell me about them!

Eight Jackalopes Walk Into An Office

July 9th, 2014 by Elizabeth Hall

Intern Group Final

As always, our interns are working on real features for our real products and have already made tremendous contributions to the Trello and FogBugz teams. We think they’re pretty special – not only did they stand out amongst the 776 applications we received but during these first few weeks they’ve had the chance to teach us a thing or two. Whether it’s coming up with new strategies for dealing with the Tanner during Werewolf or showing off cool video games they’ve made at hackathons, the class of 2014 is constantly impressing us.

Before we blink and it’s all over we want to take a moment to show off this year’s amazing talent. Here they are our eight wonderful interns (lovingly dubbed jackalopes*) in their own words.

Alex Lew

Hi! My name’s Alex, and I’m an intern on the Platform team this summer. Obligatory fun fact: I grew up in North Carolina, and my high school’s library had the largest collection of books and music in and about Esperanto of any library in the United States (excepting the Library of Congress).

Laura Watiker

My name’s Laura and I’m working on the Trello team this summer. During the school year, I go to Oberlin College in Ohio, studying CS and Econ. I grew up in the New York City suburbs, but I’m happily living in the Brooklyn housing this summer. Aside from pushing lots of computer keys, I do work with Oberlin’s co-ops, play a bunch of instruments, and theorize 2048 strategy.

Graham Carling

My name is Graham, I just finished my Sophomore year at Brown. I am originally from Manhattan and a graduate of Stuyvesant high school, a short walk from the Fog Creek offices. I am majoring in Computer Science (I know, shocking) and for the last couple semesters I have been working as a TA for some of Brown’s CS classes. Outside of work I like going to concerts, mainly of the electronic variety, along with seeing my friends from high school and working on a side project of mine. So far my summer has been packed full of fun events, and when I’m not going fishing or shooting arrows I’ve been working on the new notification center feature for FogBugz.

Jonathan Pevarnek
Hello, I’m Jonathan, a masters student in Computer Science at the University of Michigan. I’m from a small island called Grosse Ile in south-east Michigan. When I’m not working, I like to read books, go on bike rides, and work with a campus community service organization (Circle K). This summer, I’ve mainly been working with Doug to extend Trello email integration.

Matthew Hayes

I am Matthew Hayes, from Syosset, Long Island, NY. I just finished my junior year as a CS major at Cornell University upstate in Ithaca, and will be working on a FogBugz activity feed this summer. Fun fact: I caught the biggest fish on this year’s fishing trip (evidence below).

Peter Johnson

My name’s Peter, and I’m working on adding saved searches and list sorting to Trello this summer. I just finished my junior year at William & Mary in Virginia, and in my free time I enjoy running long distances and playing Dots!

Steven Lyubomirsky

If you’re inclined to take me at my word, my name is Steven Lyubomirsky, I’m a rising junior at Princeton, I study computer science, and am incredibly handsome. If you’re not, at least three of those can be independently verified. I live under the watchful guard of my blue parakeet in Fort Lee, NJ, a safe distance from the incredibly radioactive center of the universe (NYC, of course), where I like to demarcate my domain with my nightly walks. This summer I’m working on the Platform team.

David Patrzeba

My name is David Patrzeba and I am an intern on the FogBugz team (Project Jackalope). I started on June 6, 2014 because the newest addition to my family decided to arrive on my original start date of June 2, 2014. I am a NJ native and will be traveling home every weekend to be with them, but during the week I will be staying at the Clark St. residence in Brooklyn. I am a rising senior at Rutgers University (The State University of New Jersey) where I am studying Electrical & Computer Engineering, Computer Science, and Economics. Fun Fact: I served in a Special Operations unit in the Army for 7 years, and I may be Fog Creek’s oldest intern ever.

Matt wasn’t lying. He really did catch the biggest fish.

*Each year the intern class is named after the next letter in the alphabet. This year is “J”. Do you have a fantastic “K” animal name recommendation for next year? Talk to me!

Fog Creek and Heartbleed

April 10th, 2014 by Mendy Berkowitz

Along with the rest of the internet, Fog Creek has been reacting to the Heartbleed vulnerability which was discovered this Monday.

TL;DR: FogBugz and Kiln On Demand, Copilot and the Fog Creek website were not vulnerable. Trello was vulnerable and has been remediated.

Fog Creek handles SSL connections at the load balancers in front of the application servers. The load balancers for FogBugz and Kiln On Demand, Copilot and the website are using the 0.9.8 branch of OpenSSL. This version does not have the newer heartbeat extension and is therefore not vulnerable to Heartbleed. None of your data on,, or has been exposed to the Heartbleed vulnerability.

The load balancers for Trello were using the 1.0.1 branch of OpenSSL and were vulnerable. We have upgraded OpenSSL and replaced the Trello certificates. More details and important recommended steps for all users are available in a post on the Trello blog.

We have also reviewed our vendors (for things like this blog) to ensure that our other SSL certificates were not potentially compromised. Fortunately we have not had to replace any other certificates.

If you have configured web hooks in your Kiln On Demand account, we recommend that you verify that the target servers have not been affected. If you use one of the pre-configured types, or your custom web hook uses HTTPS, the data sent to that external service may be at risk. We do not however, send any of your Kiln login credentials, so they are safe.

We take the security of your data seriously. We are committed to protecting it and to maintaining clear and open communication with you. If you have any questions, comments or concerns please contact us.

Fog Creek’s Ad Hoc Remote Work Policy, or, Working From Grandma’s House

September 12th, 2013 by Rich Armstrong

Not grandma.
Not grandma.


Once every few months someone walks into my office and says, “Hey, I’ve got this (reunion|wedding|grandparent). I’d like to figure out how to spend some more time with my family. Can I work remotely from my grandma’s house for a few days?”

I always said yes, and got pretty uneven results. When someone wasn’t productive, it was usually due to unforeseen circumstances that seemed obvious after the fact. So we started a list of things you’ll need for a short stint of working remotely. This list is a “policy” inasmuch as it represents all the things you need to do in order to be “covered” while working remotely for a short stint. If something foreseeable comes up that’s not on this list, then it’s our problem, not yours.

Two important things that this is list is NOT applicable to:

  • Working from home waiting for the cable guy or a mattress delivery. That all happens under your usual flexible work arrangement.
  • Going somewhere you’ve never gone before, like a cabin in Iceland or an apartment in Paris, where you don’t know what the infrastructure will be like. We’ll call this “working from Borneo”. We’re not against Borneo, mind you. It’s just not what we’re talking about here.

One thing this list is kinda applicable to:

  • Permanent remote work. After writing this all down, we realized that almost everything we’d recommend to the short stint people applies to people working remotely. We’re still learning from them, so might have more to say later.


  • A computer to work on. Duh.
  • “Approval” from your team lead. We’re not big on bureaucracy here, but this is just common courtesy.  Most of what you’ll have to do is covered below in “known availability”, but you should start with talking to your team lead.
  • An internet connection capable of easily handling a Google Hangout. Since we’ve opened up to remote workers, Hangouts have taken the place of conversations in the hallway and standups in someone’s office. Downstream is usually not the issue. Most basic internet plans are at least 5 mbps down, which is no problem. Being able to participate in a video conference usually means more that 1 mbps up. A lot of cheap internet service only offers 1 mbps up. How do you know if Google Hangouts will work where you’re going? Do a test Google Hangout with a person at the place you are going to be! (If there’s no one on the other end to do this with, the place you’re going is either vacation or Borneo (see above).)
  • Access to the resources you need to work. Make sure you can:
      • log in to your laptop as a local administrator without connecting to the Fog Creek network. This is especially true for Mac users, as Macs do not cache your credentials
      • connect to the VPN from your new location. Not all Internet connections, or routers, are created equal and not all will allow you to get on the standard VPN
      • RDP into your HQ machine, if you don’t have everything you need on your laptop

    If you’re unsure about any of this, talk to the sysadmins before you discover you can’t work remotely.

  • A headset. The built-in speakers and microphone on your laptop/monitor suck. The added friction of talking to someone without a headset makes your team members not want to invite you to a Hangout, which means you miss communication that you would normally have received.
  • A dedicated room with a door that closes. At Fog Creek, devs have offices with doors that close. People who aren’t devs are surrounded by coworkers who’ve learned to keep from inadvertently distracting each other. Your aunt has not learned this, so it’s probably a good idea to sequester yourself as much as is feasible. You need a place that is as distraction-free as your normal work environment, and maybe a little more.
  • No child care responsibilities during working hours. You can’t take care of kids and work at the same time.
  • Known availability and overlap with your team. Set standard hours and make sure people know them. If you’re not going to be working the hours you normally work, overcommunicate this to your team by posting in chat (ex: “Going to the gym for an hour”). Nothing is more frustrating to team productivity than chat messages like “Has anyone seen X?” “When is X getting online?” “Can someone else take this bug? X isn’t responding.” Try not to pop in and out. Work sustained sessions with only a few significant interruptions (e.g., lunch, dog walking, gym, light-saber fight with your nephew).
  • A dedicated phone that fits into your position’s workflow, where applicable. If you are an employee who spends a reasonable amount of time on the phone, it should be relatively easy for people to get you on the phone and for you to call them. This might require you to contact the sysadmins for phone forwarding. We haven’t done a lot of this yet, so we’re not awesome at it. Maybe you can use your experiences here to make the next person awesome?


Suggestions for Short Stint Remote

When you’re used to working in the office and you leave it, you’re like a snail without a shell. Consider these suggestions a temporary exoskeleton. These suggestions are not because we don’t trust you. We trust you. To get a desired effect, we often accentuate parts of our behavior that don’t come naturally. We might be introverts at a networking event, forcing ourselves to start conversations with strangers. We might be on camera, forcing ourselves to oversmile like idiots. Most of these tips are to encourage unnatural but beneficial behaviors.

  • Don’t be coy. Awareness is largely covered in “known availability” above, so this bullet point covers your mental state. You might be tempted to downplay your absence from HQ. Puritan work ethic runs pretty deep with some.  Fact is you can ship like an animal from places like Hawaii or Cape Cod (where this document was started). But you might be embarrassed to talk about it, or you might be put on the defensive by someone saying “Great beach weather.” Ignore it and ship code. Clamming up or playing down helps no one. It’s the opposite of what we want; it’s the main reason we have a policy. If you’ve met the requirements above, you’re covered. You are not slacking. You are working. You should not be shy about letting people know where you are and what you’re doing because of what they might think.
  • Put a note on your monitor saying where you are and for how long, in case people wander by looking for you.
  • Have boundaries. The people you’re going to be around might not understand that, yes, you will actually be working. Don’t worry. Your in-laws/parents will be impressed by your work ethic!
  • Over-communicate and/or over-deliver. At HQ, you have a few ways of staying involved and available (face time, informal chats, lunch) that are not available to you remotely. You still have stuff like chat, commit messages, code reviews, cases, Trello boards, etc. If you’re a Creeker, chances are good you’re a low-key person who doesn’t crow about their achievements. You might want to flip that bit for this stint. That can be hard, but it’s important to keep involved. The best way to do this is….
  • Have a deliverable. This frees you from having to assert your productivity via chattiness.

That’s it! We put this stuff out there so that you can effectively take advantage of the flexibility offered by your work arrangement and continue to be productive as part of your team. If you learn something while setting up your environment, or while working remotely, that you wish you’d known earlier, please let me know. The list you see above is a work in progress.

Dogfooding Until It Hurts

February 26th, 2013 by Rich Armstrong

Dogfooding. Also called “eating your own dog food.” It’s pretty simple, right? If you work at Uber, maybe take an Uber car ride from time to time. If you work at Khan Academy, you’re probably pretty good at math by now.

In this video from 2009, Joel talks about dogfooding as being more than just using your own product. It’s about using your own product for everything you can imagine, even if that usage is a little uncomfortable.

We dogfood Trello, FogBugz, and Kiln in a ton of different ways.

We’re a software company, so we generate a lot of code. Kiln helps with that. But we even use it to hold things that aren’t “code” per se, such as backups of non-sensitive databases. We don’t have any real crazy use cases, like using code reviews to plan parties or the electric DAG to create subway maps, but that’s just because Kiln has only been around a few years.

FogBugz, on the other hand, we use for tons of off-label stuff. We use FogBugz’s crash reporting ability to read RSS and Twitter feeds and create cases when new items appear. We use its customer email capabilities to receive faxes. And we have a panoply of API scripts automating a bunch of different business processes.

Trello is a natural for dogfooding, of course, because it’s so flexible. We keep kitchen snack requests and lunch menus on boards. We keep track of who’s going to what conferences, and use it to plan their travel. Trello really shines in setting the agenda for and running our bi-weekly company all-hands meeting. Because Trello is so flexible, it invites a lot of different use cases. We’re still figuring out which ones really work, and it’s great to see a fast-growing user base figuring that out alongside us.

So, that’s all well and good, but if you really want to see “dogfooding until it hurts” in action, check out Beeminder, a tool for setting “goals with a sting.” You set up your goals, and if you stray from them, the service fines you an escalating amount of real money until you’re back on track. Beeminder is dogfooding heavily and publicly to keep their development goals on track. These folks are  literally giving away cold hard cash to users as a pre-commitment to do things like delivering user-visible enhancements or blog posts on a regular basis. Amazing. Even better, they have a Trello integration that’ll keep you moving those cards to the Done column regularly (or else).


Let Them Have Cake … And Ice Cream Too!

November 17th, 2011 by Rock Hymas

Consider a cake shop owner in a small town in Siberia. He sells the best cake around. Whenever someone wants a treat after dinner they stroll down to the cake shop and get a nice big slice of cake. But along comes a new treat: ice cream. Our cake shop owner ridicules his neighbor for starting an ice cream stand, saying no one will buy it because it’s cold. This is Siberia, after all. But rather than running an oven all the time, she can just keep her ice cream outside in the freezing cold, so it sells for less. Suddenly a whole bunch of people who could never afford cake are stopping at the ice cream stand after both lunch and dinner. It’s cheap, it tastes good, and the teenagers are having contests to see how much they can eat before passing out from brain freeze. It seems the whole town is there, and some of the cake shop customers start getting ice cream just because they want to hang out with their friends at the ice cream stand. All of a sudden the neighbor is rolling in the dough and she wants to buy out the cake shop since they have a great location.

Now suppose the owner of the cake shop recognizes that lots of his customers will like the ice cream (even in Siberia) because it’s so much cheaper. So he sets up an ice cream stand and hires his neighbor to start selling it as fast as possible. He notices that some of his regular cake shop customers are going to the ice cream stand instead, because it’s cheaper. So cake sales are down a little. Rather than shutting down the ice cream stand though, he brings it into the cake shop, adds a special “cake” flavored ice cream, and becomes the town hero. Not only has he saved his business, but he’s also been able to meet the dessert needs of more of his fellow townspeople. Cake is selling even better than before, ice cream is selling even better than that, and the cake-fanatics and ice cream groupies all get to hang out together.

Clayton Christensen’s talk at this year’s Business of Software was all about how companies disrupt, and are disrupted by, other companies. In building a product, you (or those who came before you) made decisions that are really hard to change after the fact. That’s fine; those “stakes in the ground” are what made the product successful. But it also limits the viable lifetime of the product. At some point disruption happens.

Disruption =

Larger Market + Lower Price + Different Measure


Professor Christensen pointed out that disruption occurs when a company solves a given problem for a larger audience at a lower price point with a different measuring stick for comparing value. Companies that successfully avoid being disrupted are usually able to do so only by disrupting themselves. Few companies are able to pull that trick off, and it typically involves having a different team or business unit set up in order to avoid all the baggage that the last-generation products carry with them.

What does this have to do with Fog Creek? Well, I’ll admit that I was a little skeptical when Fog Creek launched Trello. My worries pretty much lined up with those outlined in this post from a FogBugz customer. Though it’s taken some time, I’m starting to see how important it is for Fog Creek to prepare for the disruption of its flagship product, FogBugz.  By doing so, we can make sure FogBugz will keep solving our customers problems and keep making us money.

Trello fits the model for disrupting Fogbugz. It solves the problem of planning the work on a project for a larger audience than just software companies, at a lower price point than a FogBugz or a Jira, with a different measuring stick: putting Trello and FogBugz next to each other on a feature comparison chart doesn’t make any sense.

Trello’s target market is much larger than that of FogBugz. Where FogBugz targeted software development teams with features like bug tracking, automated crash reporting, and evidence-based scheduling, Trello can provide value to any group of two or more people working together on something that can be broken down into steps. Even though any group of people could use FogBugz to do the same thing, using FogBugz doesn’t really make sense when you’re in HR doing hiring, or in law working through cases, or in a studio vetting country bands. Using Trello does.

Additionally, Trello has a lower price point: free. Everything currently offered by Trello is free, and will remain so going forward. Yes, there will probably be value-added features and services that Fog Creek will charge for at some point. Compared to free, though, FogBugz is expensive at $25 per user per month. When you just want something simple to plan your wedding, that doesn’t make any sense. But if you’re managing software projects for reasonably complex products, then FogBugz easily adds that much value, and our customers make that clear by coming back again and again.

Trello also has a different measuring stick. And that’s the real reason it will eventually overtake FogBugz, even for software projects. Or rather, it will take over some of the roles that FogBugz fills in a software development company. We already use it here at Fog Creek to manage our work at a coarse-grained level. It provides a potentially public view into product development, which is cool to see.

The real key, though, is that Trello, like FogBugz, is opinionated–but it has very different opinions. Rather than seeing work on a project as a large set of small items that need to be tracked individually, it sees project work as a small set of somewhat larger tasks that fit into a bigger whole, a workflow defined by the team. If FogBugz tried to create some kind of dashboard view of your bugs to compete with Trello, you’d be so overwhelmed by minutia that you’d give up and walk away. No one wants that kind of view when they’re dealing with hundreds or thousands of individuals cases. But Trello redefines the way we see our project work and that fundamentally changes the game.

Wait a sec! I’m on the FogBugz team. What am I saying?! Am I just making a Steve Yegge “TMI” mistake by posting this publicly? Am I talking myself out of a job?




I don’t think so. And here’s why.

The same legacy that prevents it from winning in the larger Trello market gives it a competitive advantage in the market for software development teams. FogBugz will continue to make money, and it is still growing at a nice pace. It needs investment, but not the kind of investment that would attempt to turn it into Trello. Rather, the kind of investment that will take advantage of disrupting products like Trello while preserving it’s usefulness in the niche of software development teams.

And our customers, for the most part, aren’t going to jump ship for Trello anytime soon. Currently, Trello can replace only a very small part of what FogBugz provides. One customer pointed out that it cannot handle bulk editing, screenshot captures are painful, and categorization and search aren’t designed for the situation where you have lots of items. Additionally, FogBugz supports incoming and outgoing email, automated crash reports, and deep hierarchies of work. You can install it within your network and use it completely internally. It’s also got awesome source control integration with Kiln. These are all things that software development teams care about, often passionately. Trello, and other products like it, may eventually meet some of these needs, or integrate with other tools that do, but that will take time. Time that will allow FogBugz to further differentiate itself.

Besides, learning new ways of working is hard. Anecdote time! We spent some time over the last few months rethinking the UI for FogBugz. As the team lead, I made the call to focus on that, and did what I could to protect the team through the process. Unfortunately, when it was done, Joel pointed out that it wouldn’t fly with our customers. Why? Because we “moved the cheese” in too many ways. It would have required our customers to learn new ways of working, and human nature doesn’t like to do that. Though that does limit what we can do with FogBugz going forward, it also strengthens the ties that our current customers have with the product. They know where to click, which keyboard shortcuts to use, and they know what to expect. That helps them work faster, get in the flow, and keep the boss happy.

Finally, and related to the last point, FogBugz has an ecosystem of supporting technology around it. When our customers start using FogBugz and Kiln, they often integrate with a set of tools and technology. This is one reason it’s harder to innovate on those products, because our customers don’t just rely on not having to learn new ways of working, they also rely on their custom plugins not breaking, on their random Python scripts still working, and on third-party tools continuing to integrate well with FogBugz. Each of those is a barrier to entry – they make it harder for a competing product to win our customers away from us (yep, even if the competitor is made by us as well) because they also add value for the customer.

In short, for almost all of FogBugz existing customers, and most of the larger market of customers using a competing bug tracker, using Trello instead is not the right business decision. And within that market FogBugz can make sure that business decision doesn’t change by doing the right kinds of investment. Investment that will keep FogBugz relevant and growing into the future is core-competency investment, not more features or chasing faster competitors in a race decided by a radically different “finish line”.

And there are tons of things we can do in the core of FogBugz: reduce the complexity of the product both for our users and for our developers; make it faster; phase out old features that aren’t being used by anyone; fix the backlog of bugs; improve our up-time; integrate with Trello and other apps. That last point is probably the most salient. As Trello grows and becomes a better fit for certain kinds of project management work, FogBugz can increasingly integrate with and offload those areas to Trello. At the same time, it can target specific problems that software development teams face, and provide value by solving them well.

In the end our customers will be able to have their cake … and their ice cream too.

The Price of (Dev) Happiness: Part Three

October 11th, 2011 by Rich Armstrong

Buying lunch in lower Manhattan is not cheap. If you don’t brown-bag, you’re pretty much in for nine bucks, and more if you want to sit down. A meatball sub is $8.50. The Hanover Square Deli does a respectable dduk mandu guk for about $9.50. A meager-looking, but tasty, turkey and guacamole sandwich from British import Pret A Manger will set you back $6.75 (plus tax). Or, if you really want to eke out some savings, you can get a cup of soup and a hunk of bread for about $5.

Post-lunch, Pre-espresso machine

At Fog Creek, we have our lunch catered every day.  The cost of this to the company is $15.75 per person per day. Not counting drinks and snacks, this amounts to an extra $4,000 per year per employee. So why wouldn’t we just pay people $4,000 a year more? If they want to be frugal, they can buy that $5 soup and pocket the difference.

Well, first off, since lunch is a catered on-site meeting, the cost of that lunch is 100% deductible as a business expense. If you worked here, it’d cost the company $16 to give you $10 to go buy your own mediocre udon noodles.  (Don’t take any taxability or corporate expense stuff here too seriously; I’m not an accountant or lawyer.) Second, Fog Creek’s free lunch is much more because of how it fits with the rest of our workspace and culture.

Free lunch is nothing new. Google and other big tech companies have been giving their employees breakfast and lunch (and sometimes dinner). Free lunch has been around for more than a decade because it works for attracting and retaining top talent. (Or, rather, people think it works.)

Now, the food at Google, and the people who make it, are awesome. The food at Fog Creek is good, but nowhere approaching what Google does. We don’t have Sam, the sushi chef, doing hand-rolls to order. We don’t do miso black cod, lamb shanks, or osso buco. We don’t have a raw vegan station with selections so delicious they attract the most dedicated carnivores.

Here’s what we have at Fog Creek instead: no meetings.

For us, lunch is our only recurring meeting. The only standing interruption in the day/week of a developer here. Everything else is ad hoc or temporary. (One exception is our quarterly meeting to go over financials and to grill the founders with questions.) The default at Fog Creek is no recurring meetings. Once you’ve established that, recurring meetings become the exception, rather than the rule, and tend to wither naturally as their usefulness degrades over time. For example, the FogBugz team is currently doing a stand-up meeting for fifteen minutes every day right before lunch, but this won’t last. The Trello team was doing them before and shortly after launch, but they’ve subsided.

The Kiln team lead assures me that their weekly stand-up is a real recurring meeting, but at some point they’re going to lose interest and go back to coding. It’s what they do. Meetings have a network effect. They need other meetings to legitimize them. If you’re constantly scheduled with meetings, you don’t mind being interrupted one more time. Or, rather, you don’t have the energy to protest. When you proceed from the assumption of no meetings, you have to expend effort to keep a meeting going.

It’s not all a playground, of course. There are downsides. Things, sometimes important things, don’t get communicated to the right people at the right time. More often than not, the worst result is hurt feelings or slight confusion. Sometimes it’s more than that. But we wouldn’t give it up.

For someone who’s used to a standard work environment, it seems silly, cult-like, possibly even daunting, to be “forced” to break bread with your colleagues every day. It seemed odd to me before I came here, but by the end of the first week, nothing seemed more natural. When most of your “socialization” with your colleagues takes the form of mandatory, recurring meetings over a conference table, it’s natural to not want to see them again over the lunch table. People have been making decisions about your time all day; at lunch, you need some time to yourself.

But when most of your time is spent working in a private office, taking breaks according to your natural attention span, having short chats with one or two colleagues, it’s a pleasant prospect to surface for some pleasant conversation about StarCraft or football with nice, intelligent people. And maybe you’ll hash out that new feature, too.

One can make the argument for free lunch based strictly on developer productivity. A free lunch could give you a hundred hours per year from your best people, time saved in driving, waiting in line, etc. But, consider the depressing ease with which such a gain can be wiped out by a few recurring meetings.

So, for our final post in this series, we do have a number: $15.75 per day. $4,000 per employee per year. It’s a lot of money. But without the rest of the company culture, it would be sort of meaningless. A sense of entitlement grows rapidly around any perk you offer, and lunch is no different.

A lot of this series has been based on getting hard data out there so that developers, our main audience, have an easier time talking to management about some of the things that’ll make them more happy, healthy, and productive. For this post, it’s a bit more difficult. You might get your boss to spend $16 a day, but changing the culture of meetings in any workplace is nearly impossible. (During my tenure, Google tried no-meeting Thursdays and formal meeting-reduction task forces, reminiscent of Brazil’s Ministry of Debureaucratization, to no avail.) It would require rebuilding the company culture from bedrock.

Our bedrock is the idea that, once we’ve hired good people, it’s the effort we make to direct their intention, rather than their attention, that creates value. It’s not just our lunch benefit that springs from that, but nearly every other thing we do.

For Fog Creek, our founding principles, and the pains we take to stick by them, are the price of developer happiness, and that can’t be measured in dollars.


Experiments with Google Page Speed Service

September 23rd, 2011 by Jude Allred

Our oldest product

Let me tell you a little bit about

  • It’s old; It’s hosted by IIS6 alongside a horde of other websites.
  • It’s the first place people go when deciding whether to use FogBugz or Kiln.  It’s pretty important to us.
  • Recently, we started to treat the website as a product. It has received substantial attention, primarily in the form of A/B tests.

We’re building some fancy new web servers for, but in the meantime we’ve been accepted into the Google Page Speed Service beta. It seemed reasonable that it might provide us with some useful tools, and in the short term it might give us a workaround for some of our IIS6 woes.

There were four things that we hoped Page Speed Service would take care of:

  1. GZIP all of’s static and dynamic content.
  2. Set far-future expires headers on our static content.
  3. Distribute our static content via a CDN.
  4. Fix or remove the broken ETags that IIS 6 Is sending out.

Enter Google Page Speed Service

For this test, we brought Google Page Speed Service to life at This is a totally unused alias of, so we were able to test PSS on an isolated mirror of our production environment.

After a small amount of setup, page speed service was live!  (Setup basically consisted of adding a Google verification .txt record and a CNAME record mapping to

The comparison tool that Page Speed Service provides was inconsistent, but it looks like there might be a lot to love.

  • Its page load times differ from those reported by GTmetrix and local testing
  • The measurements change significantly over the course of running it multiple times

But the results look promising.  Here’s a report on Fog Creek’s home page load time.  On the left is the load time without Google Page Speed and on the right with it.  Google PSS gave us a 10% difference in initial page load time, and a 25% difference in repeat page load time. We got that for very little effort.  Nice!

Here are GTmetrix reports on from 9/23/2011.  First, the results without the Page Speed Service:

And the same tests on, with Page Speed Service enabled:

Overall scoring improvements:

The Fog Creek landing page:

Google PS +1%, YSlow +10%, page weight reduced from 466kb to 365kb

The FogBugz landing page:

Google PS +1%, YSlow +12%, page weight reduced from 608kb to 379kb

The Kiln landing page:

Google PS +0%, YSlow +10%, page weight reduced from 520kb to 411kb

Interestingly, GTmetrix shows page load times (as measured by the onload event) that are consistently slower for than, usually on the order of about 0.7 seconds.

GTmetrix’s tests don’t seem terribly consistent with’s (Google’s promoted testing service), which show consistently faster page loads than GTmetrix. But, it’s hard to draw conclusions since incremental rendering of the page is an important factor which isn’t represented by the load time.

For those of you who wish to dig deeper, take a look at the waterfall diagrams of a given page rendered with or without PSS. You’ll notice that the PSS timelines have their content proxied across 4 of Google’s servers, the overall number of requests has decreased, and the waterfall has rearranged significantly.

For example:, Without Google Page Speed Service:, With Google Page Speed Service:

So how did PSS handle the goals we wanted to meet?

  • PSS has compressed (GZIP) the content that it sends down
  • PSS has far-futured the vast majority (but not all) of our static content
  • PSS has properly configured our ETags
  • PSS is distributing our content via its CDN


1 - PSS’s lossless image compression is lossy.  Our website uses a tiled, textured background image.  Page Speed Service attempted to optimize it, and in the process altered the background images.  For example, this image:

Became this one:

I’ve put together a test case at

As part of the lossy conversion, PSS converted the image from a png into a jpg.  I altered the source image files to be jpgs instead of pngs, and then PSS was able to optimize and bundle them without any difficulty.   I’d also note that the image optimization step (and all of their other optimizations) can be disabled in order to work around problems like this.

2 - PSS supports blacklisting URLS, but not blacklisting HTTPS urls.  I knew from the start that PSS didn’t support HTTPS, and therefore our trial signup forms, e.g.,, would have to be exempt from PSS’s optimizations.

PSS supports blacklisting, which allows you to exempt a specific page from being hooked by PSS’s proxy.  Instead it will go directly to your source server.  Unfortunately you can’t configure HTTPS pages in this manner.  If you have a website with HTTPS content, you’ll have to move all of your HTTPS content to a separate subdomain, e.g. “”, in order to exempt it from PSS.

This was an inconvenient change to make, although not hard. Still, PSS’s support of blacklisting was put to good use.  We use a heavily-modified version of the FairlyCertain A/B testing framework on our properties.  Server-side A/B test frameworks and CDN’s don’t really play well together, but PSS’s blacklisting allows us to blacklist any pages which contain active A/B tests.

3 - For the duration of the beta, once you bring PSS live on a given subdomain (e.g.,, you cannot reconfigure PSS to work with a different subdomain (e.g., without an additional beta acceptance.  I’ve reapplied to include in the PSS beta, but have yet to be approved.  For this (and only this) reason, we’re blocked on moving forward with using Google PSS in production.  If a Googler is reading this and would like to whitelist for the beta, we’d be much obliged.


Pitfalls and onload-event oddities aside, I’m very impressed with Google Page Speed Service.  I’m happy to see that they’re abstracting away the ever-present need to minify, compress, and bundle your static website content, as well as optimize your images.  In our specific case we don’t really care about those  features – we already optimize our images and bundle our scripts, but it is a great feature for most sites.  Our case is probably more edge than common—we’re using PSS primarily to work around IIS6, and it appears to succeed at that.  PSS’s CDN seems promising, but I don’t yet have any data on how it compares to, say, Amazon’s Cloudfront service.  Setting up PSS on our site was an absolute breeze, however, and  I think it may turn out to be a great tool for web developers and site administrators.

The choice of setting up the Page Speed Service on instead of our production subdomain, retrospectively, was a useful mistake.  I appreciate the ease of using tools like GTmetrix to compare the two subdomains directly. I’ve also enjoyed keeping PSS’s configuration changes completely separate from our production environment as well as the ability to share the PSS changes with other people without having to manually configure their browser to proxy traffic through PSS.

Looking for more?

Visit the Archives or subscribe via RSS.