Archive for the ‘General’ Category

How Fog Creek Got Started

November 20th, 2014 by Gareth Wilson

Starting out as a consulting company in 2000, Fog Creek was founded with the goal of creating the best place for developers to work. The video covers the early years of Fog Creek. Hear from our founders, Joel Spolsky and Michael Pryor, how they navigated the Dot-com crash and bootstrapped the company in to a growing, product-based business.

Effective Code Reviews – 9 Tips from a Converted Skeptic

November 17th, 2014 by Gareth Wilson

I knew the theory. Code reviews help to:
code_review

  • Catch bugs
  • Ensure code is readable and maintainable
  • Spread knowledge of the code base throughout the team
  • Get new people up to speed with the ways of working
  • Expose everyone to different approaches

Or, they’re just a giant waste of time. At least, that was my first impression of code reviews.

I was the new guy, a recent grad, developing plugins for a software company in London.

Over time I had to submit blocks of identical or similar code. They would get reviewed by the same poor, put upon guy (“he’s the best at it” my manager told me. No good deed…). Yet each review would come back picking at something different. It seemed needlessly picky and arbitrary.

Worse still, reviews would take days, if not weeks. By the time I got my code back I could hardly remember writing it. It wasn’t the guy’s fault. He’d asked for a senior dev, but had gotten me. He was sick of dealing with the issues every inexperienced developer makes, and code reviews were his way of exorcising that frustration.

Add to this the time lost in syncing the different branches, the context-switching… I was not a fan, nor were the rest of the team and it showed.

Skip forward a few years though and I find myself nodding along whilst reading a tweet quoting Jeff Atwood:

“Peer code reviews are the single biggest thing you can do to improve your code.”

What I had come to appreciate in the intervening years is that it wasn’t that code reviews were bad. Code reviews done badly were. And boy, had we been doing them badly.

I had learned this the hard way. And it certainly didn’t happen over night. Although on reflection, code reviews have saved me from more than a few embarrassing, build-breaking code changes! But after I had worked elsewhere, I gained experience of different and better ways of working. This gave me opportunity to see first-hand the benefits of code reviews that I had dismissed before. So now I consider myself a converted skeptic.

So that you can avoid such pains, check out our video and then read on for tips that will skip you straight to effective code reviews.

9 Code Review Tips

For everyone:

  • Review the right things, let tools to do the rest

    You don’t need to argue over code style and formatting issues. There are plenty of tools which can consistently highlight those things. Ensuring that the code is correct, understandable and maintainable is what’s important. Sure, style and formatting form part of that, but you should let the tool be the one to point out those things.

  • Everyone should code review

    Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But more important is maintaining a positive attitude to code review in general and that means avoiding any ‘Us vs. Them’ attitude, or making reviewing code burdensome for someone.

  • Review all code

    No code is too short or too simple. If you review everything then nothing gets missed. What’s more, it makes it part of the process, a habit and not an after thought.

  • Adopt a positive attitude

    This is just as important for reviewers as well as submitters. Code reviews are not the time to get all alpha and exert your coding prowess. Nor do you need to get defensive. Go in to it with a positive attitude of constructive criticism and you can build trust around the process.

For reviewers:

    code_review_in_comfort

  • Code review often and for short sessions

    The effectiveness of your reviews decreases after around an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout your day to coincide with breaks, so as not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.

  • It’s OK to say “It’s all good”

    Don’t get picky, you don’t have to find an issue in every review.

  • Use a checklist

    Checklists ensure consistency – they make sure everyone is covering what’s important and common mistakes.

For submitters:

  • Keep the code short

    Beyond 200 lines and the effectiveness of a review drops significantly. By the time you’re at more than 400 they become almost pointless.

  • Provide context

    Link to any related tickets, or the spec. There are code review tools like Kiln that can help with that. Provide short, but useful commit messages and plenty of comments throughout your code. It’ll help the reviewer and you’ll get fewer issues coming back.

 

Register Now for ‘Code Reviews in Kiln’ Webinar

Join us this Thursday, November 20th at 1:00 PM – 1:30 PM EST for our ‘Code Reviews in Kiln’ webinar. This webinar will help first time or novice users learn the basics of Code Reviews in Kiln.

We’ll cover:

  • What are Code Reviews
  • Why use Code Reviews
  • When use Code Reviews
  • What to look for during Code Reviews
  • Creating a Code Review
  • Commenting and Replying on a Code Review
  • Code Review Workflow

Secure your spot, register now.

Scaling Customer Service by Fixing Things Twice

November 10th, 2014 by Gareth Wilson

As a bootstrapped company we’ve always had to work within a budget and avoid unnecessary costs without harming our mission. One area that has the potential for suffering in the face of limited budgets is Customer Service. When a company is growing, customer service can suffer or it can grow to consume a considerable amount of your budget. We’ve been able to grow our customer base by more than 10 times, maintaining a high level of customer service while keeping our support costs manageable.

How? By Fixing Things Twice using the 5 Whys.

Check out the video and read more about how these techniques can help you scale customer service without the cost.

Fixing Things Twice

When a customer has a problem, don’t simply resolve their issue and move on – but rather take advantage of the issue to resolve its underlying cause. This is Fixing Things Twice.

We think that for each customer issue, we have to do two things:
1. Solve the customer’s problem right away
2. Find a way to stop that problem from happening again

How we solve the first depends on the specific problem at hand, but to resolve the second we use the 5 Whys method.

Resolving Root Causes with 5 Whys

The 5 Whys is a problem-solving method and form of root-cause analysis. It involves recursively asking the question ‘why?’ five times when faced with an issue. Doing so enables you to get to the bottom of it, allowing you to fix and stop it from happening again.

Just ask why

This technique was recently popularized by Eric Ries in his book ‘The Lean Startup’. Yet it was developed by Sakichi Toyoda in the late eighties at Toyota. Over the years its use has spread beyond the motor industry to software development and other areas such as finance and medicine. It’s a recommended technique used by the UK’s National Health Service for example.

Lets take a look at how it works using a hypothetical situation:

  • The initial problem – The machine won’t start
  • 1st Why? – There’s no power
  • 2nd Why? – The power supply is not working
  • 3rd Why? – The capacitor has broken
  • 4th Why? – The capacitor was old but had not been replaced
  • 5th Why? – There’s no schedule to check for ageing parts in the power supply units. This is the root cause.

This technique is especially useful when you’re able to focus on processes as causes, like in the example above. Whilst other factors like time, money and resources might play their part, they’re beyond our immediate control. 5 Whys quickly exposes the relationship between the various causes of a problem – yet it does not require any analysis tools. This means it can be adopted and applied throughout an organization. We’ve extended its use beyond Support to include System Administration too. Watch the video above to see an example.

What does Fixing Things Twice mean for Support?

Here’s a couple of examples of using Fixing Things Twice provided by Adam Wishneusky, Technical Support Engineer here at Fog Creek:

When we had people asking a lot about our security practices. We fixed the problem once by giving the customer an answer. Then fixed it twice by putting up public docs at http://www.fogcreek.com/security/

Another example from a few years ago, is when we found that FogBugz wouldn’t let you create a new LDAP-authenticated user if one already existed in the database with the same LDAP UID even though that user is deleted. We showed customers how to manually fix the data to get them working, but we also pushed the dev team to fix the bug.

support and development
From this example you can see that Support must have access to the Development team. It’s often the only way the underlying issues will get fixed.

It takes commitment too – it’s easy to skip the second fix and it’s tempting to do so as it means spending more time on any one issue. But it’s a false economy to do so. When the issue crops up again and again, you’ll have to spend even more time on it.

If you stick to Fixing Things Twice then over time all the common problems get resolved. This frees up your Customer Service team to look in to the unique issues that need more time. Resolving your most frequent issues overcomes the support overhead that typically comes with adding new customers.

The Only Three Types of Meeting You Should Hold

November 6th, 2014 by Gareth Wilson

A perennial problem within software development teams is communication. Making a software company fast, nimble and effective is a function of reducing the amount of communication that takes place to a minimum. This means finding the right balance. Too much and you can’t get any work done, too little and no-one knows what to do or it’s un-coordinated.

Meetings, in particular, can be a real time sink. So to keep the balance right we actively try and reduce the number we hold. There’s only three types of meetings that work for us:

1) Mass Communication Meetings

These are meetings where you have a lot of information to communicate to a large group of people. After all, you don’t just want to send some epic email opus that no-one will read (Sorry Satya!). We have a regular ‘Town Hall’ meeting for example. In these we all come together, both office and remote staff, in the cafeteria and via video link. We hear about some pre-planned topics, suggested and organized in a Trello board. These work well because everyone hears the same thing and they only cover issues relevant to everybody.

2) Brain-storming Meetings

We use these when we just want to come up with a lot of ideas, fast. They aren’t great for discussing the ideas in detail, but can work for pure idea generation.

3) Stand-up Meetings

These are great for keeping teams on track, by providing a brief update on what you did, what you’re working on and flagging up any blockers to progress. These are especially useful in remote teams, by bringing people together you help to form that team bond. It’s important to keep them focussed though, so we’re strict and avoid over-runs and people going off-topic.

“If you have a meeting with 8 people in the room that lasts an hour, that’s a day of productivity that was lost” Joel Spolsky

And that’s it. For all others we find a more effective alternative. That might mean linking up with people on chat, ad-hoc conversations via Hangout and through extensive use of collaborative software, like FogBugz, via cases, discussion groups and the Wiki. We never use a meeting for example, when we’re trying to solve a difficult problem. Getting people together in a room just means that no-one can think things through properly. They might generate a lot of discussion, but lead to few real conclusions.

When we do have a meeting, we also limit the number of people invited to just the ones that have to be there. Those with only some relevance can catch up with the minutes added to the Wiki at a time that suits them.

We’ve found that sticking to this really saves us time. What ways have you found to minimize communication overhead? Tweet them to @fogcreek and we’ll retweet the best ones.

Improve Your Culture with these Team Lunch Tips from 20 Startups

November 4th, 2014 by Gareth Wilson

Fogcreek Team Lunch
The importance of eating together has long been recognized in positive child development and strengthening family bonds. Eating together is a great equalizer and it can be a good way to help form better and more valuable relationships amongst teams of co-workers too.

Daily Team Lunches

We swear by daily team lunches here at Fog Creek. Having stumbled across their positive impact at Microsoft, Joel Spolsky, one of our co-founders, has said that whilst “there’s a lot of stuff that’s accidental about Fog Creek… lunch is not one of them… The importance of eating together with your co-workers is not negotiable, to me.”

 

I’m similarly enthusiastic having seen the benefits myself whilst working in Support at a previous company. In my role, I was the bearer of bad news to the Development team – sending and escalating the bugs raised by customers. I had little interaction with the team beyond raising bugs, so forming positive working relationships with its members could be tough. But this was no longer an issue once we started having team lunches. They were a great way for people from different functional areas of the company to come together. We’d chat about both work and non-work stuff, and it meant that we could get to know each other as people and not just colleagues.

Long lunch tables
At Fog Creek, we deliberately have rows of long tables in our cafeteria. Having round tables means that when looking for a place to sit, you have to pick a group of people. But with long ones you just go and sit at the end of the row. You end up speaking to different people every day, helping to avoid cliques. It’s good for new hires too – they don’t have to sit alone or force themselves upon an unfamiliar group.

Like StumbleUpon, AirBnB, Eventbrite and others, we have lunch catered. It’s served up at the same time every day so everyone knows when there will be people around to go eat with. For the foodies amongst you, we share photos of some of the tasty dishes on our Facebook page.

team_lunches

Others, like MemSQL and Softwire have hired in their own chefs. And of course there’s the likes of Facebook, with their own on-site Pizza place, Burger bar and Patisserie, and Fab, who have their Meatball Shop and Dinosaur Bar-B-Que.

It Doesn’t Need to be Expensive

It doesn’t need to be expensive though – you don’t have to provide the food, people can bring their own lunch. The important part is the set time and place to eat together. Make them optional, so that people don’t feel obligated and can get on with critical work if need be.

If space is a problem, then eat out. A group at Chartio for example, eat together at a different place in San Francisco every day.

Can’t do it every day? No problem. Take Huddle, they have a team lunch once a week. FreeAgent do too and they keep things interesting by picking a different cuisine from around the world each time.

fogcreek_team_lunch2

Stay Productive

TaskRabbit, Softwire and Bit.ly have their ‘Lunch and Learn’ sessions. One team member presents on a particular topic of interest, whilst the rest munch away. Twilio use their team lunches for onboarding new hires, who demo a creation using their API to colleagues in their first week.

Small Groups or the Whole Team

It doesn’t have to be the whole team either. Warby Parker for example has a weekly “lunch roulette,” where two groups of team members go out and share a meal. HubSpot allow any employee “to take someone out for a meal that they feel they can learn from”.

Get Creative!

There are many creative ideas, too. Shoptiques provides lunch with its Book Club, LinkedIn gets in food trucks every Friday, and GoodbyeCrutches have themed lunches – “Jimmy
Buffet Day, Smurf Day, and Pirate Day” being amongst their favorites.

No Excuses

You don’t even need to be in the same country! oDesk hold virtual team lunches where its employees from the US, Russia, Brazil and India gather together and eat whilst on a Hangout.

So there you go, there’s no excuse to have another sad lunch, sat alone at your desk reading some random blog post…

How have you improved team culture at your work place? Tweet your tips to @fogcreek and we’ll re-tweet the best ones.

Sysadmin Hiring at Fog Creek

November 3rd, 2014 by Mendy Berkowitz

Here at Fog Creek we’ve spent a lot of time honing our recruiting processes. From writing the book on technical recruiting to dealing with masses of resumes. Recruiting is woven into the fabric of our company.

Our task-oriented interviewing style works for technical and non-technical positions alike, but for all the ink we’ve spilled about recruiting and interviewing, you’ll notice it is mostly focused on developers.

Interviewing developers, hiring developers, helping developers create awesome software; one might get the wrong impression that Fog Creek was composed solely of developers. And we all know this isn’t true. We have a diversity of skill sets here at Fog Creek and while we mostly hire developers, some of the other recent job listings have been for sysadmins/devops, support engineers, designers, sales, product marketing managers, accountants and receptionists.

As a member of the sysadmin team, I wanted to add some more ink to how we approach hiring sysadmins here at Fog Creek. (I’m using the term System Administrator because that is what I was called when I started my career. At Fog Creek our team responsibilities are some amalgamation of what is colloquially called SRE or DevOps or Sysadmin.)

What are we looking for in a sysadmin?

Hiring DevOps
Many of the principles of the recruiting process are the same, but the responsibilities of a developer and a sysadmin are somewhat different. Here are some of the things we are looking for when hiring sysadmins.

  • Ownership: If something is broken, fix it. We are a small company and ‘the buck stops here’. There are no other teams we can blame or foist problems on.
  • Can operate independently: We don’t believe in micro management. We need people who can take a high level task and self manage their way to completion with minimal oversight.
  • Find and Solve problems: We have a term we’re rather fond of, “Fix it Twice“. Reacting to problems after they occur is an important skill, but we must think of ways to fix things so the problem doesn’t happen again.
  • Create reasoned architectures: We aren’t biased towards any particular technology. We want to use the best tool for the job. This requires us to evaluate the pros and cons of the latest and greatest while being familiar with the old standbys.
  • Ultimately smart and gets things done.

Our Interview Process

Our interview scheme has three parts:

  • Sorting
  • Screening
  • Interviewing

Sorting

Sorting through resumes and candidates can be time consuming. I wish there was a hat to help us as we spend a couple of minutes per applicant and look for the following markers:

  • Can they write well?
  • Did they read the job posting?
  • Have they worked on tough problems?
  • Did they introduce something at work?
  • Are they passionate about technology?
  • Did they work on something that requires in-depth knowledge of the subject?
  • Do they have experience with high pressure incidents or high risk decisions?

Most of these questions are subjective. This part of the process is just to separate the blatantly unqualified or obviously disinterested. I can’t stress how important the cover letter can be in the overall process. A boilerplate “Dear Sir or Madam” letter won’t catch anyone’s eye. Referring to the job description, showing an interest in our company, showing you are just as invested in this process as we are, these are ways to stand out and make people interested in talking to you.

Screening

The next part of the processes is screening. Before we invest in a full day of interviews we conduct phone and code screens.

First, we’ll have a phone conversation with the applicant. As much as we would all love to just interact with machines most sysadmins also have to interact with people.

  • Can they carry on a conversation?
  • Can they explain what they are working on and why it is (or isn’t) important?
  • Can they take a piece of technology or an interaction that they use every day and explain the technical guts that make it work?

After the phone screen we’ll send the applicant a “take home problem” that involves solving a real world log analysis problem. The only real constraint we give is time. We provide the candidate a relatively small log file, and explanation of the format and the context of the log file. They have 24 hours from their chosen start-time to come up with a solution and send us their answer and their code. It shouldn’t matter if they send the solution in 5 minutes or 23 hours and 59 minutes. We look to see if we can understand their code, whether it works, and if it returns the correct result.

Interview

This is most common and often most difficult part of the process. You can find plenty of articles about interview questions, but we wanted ours to be as close as possible to the situations we find ourselves dealing with everyday. In the end you are hiring someone to be on your team. That means they will be doing the same types of tasks as you are doing. We tried to find generic examples of those tasks and observe how the candidate acts while performing them.

In general, a candidate will talk to five people:

  • The first interview focuses on architecture. The goal is to get them to whiteboard as much as possible. Can they plan out an architecture to solve a problem. Do they cover the components that are needed to support that architecture?
  • Second, we talk about troubleshooting. Can they figure out what is wrong (and fix it)? Can they figure out what is causing the system problem? Can they then write customer communication explaining the problem and what will be done to fix it in the future.
  • The third interview challenges them with learning through implementation. We are always interacting with new technologies. Given a pre-designed system, can they build it even if they aren’t familiar with all the components?. How do they approach things they don’t know and learn about them?
  • In the fourth interview they’ll talk to a real live developer in its native habitat. We interact with our developers and support engineers every day. Can they interact with our developers? Can they have a constructive conversation with them about code and ideas?
  • Lastly you’ll have a chat with our founders.

There you have it. This is the process we’ve been using to hire sysadmins at Fog Creek. Think you can make it through this process? Want to work in a great company with awesome people? We’re hiring!

Are You Dogfooding in to a False Sense of Security?

October 30th, 2014 by Gareth Wilson

Dogfooding
Like many of you, we’re keen Dogfooders here at Fog Creek. Since the phrase took hold at Microsoft in the late eighties, the practice of using your own products to help test them before wider release has become widespread throughout the tech sector and beyond.

And with good reason. Forcing yourself to use your own products means you end up fixing bugs before creating new features. It means you spot and resolve pain points before your product is out of the door. It also means spreading product knowledge throughout your organization.

Hear some more about Dogfooding here at Fog Creek in the following video:
 

But are you just Dogfooding yourself in to a false sense of security?

Consider the following questions:
 

  • Just how typical a user of your product are you?
    Few are lucky enough to develop products for people exactly like themselves. Here are Fog Creek for example, treating our developers well is a top priority. So typically that means we’re trying our software on a new Mac with a couple of high-res 30″ screens, probably using Chrome. That’s not to brag, but some of our customers might not be so lucky. For them the norm might be an aging PC, with a small screen and of course, forced use of Internet Explorer. If we just relied on Dogfooding, we’d be missing a bunch of browser, layout and design issues.
  •  

    • Also, when was the last time you:

    • Created a new account in your software?
    • Started from scratch rather than upgrading from a previous version?
    • Tried migrating from a third-party solution?

     
    These are all common scenarios for customers, especially new ones. Yet these are all missed in typical Dogfooding.

  •  

  • Just how many customers only use your own products?
    I’d wager most use some hybrid mixture of yours along with some from other vendors. After all, it wouldn’t be unwise for an experienced IT administrator to preach use of a range of products so as to avoid vendor lock-in.

    What’s more, if you’re only using your own tools then it can lead to a form of myopia. You become so tied to your own solutions that you fail to see better alternatives. Take Uber for example. They’re disrupting the Taxi industry not because of their decades of experience in the sector, but almost because of a lack of it. They approached the space with a fresh perspective, which meant they could see another way of doing things.

  •  

  • Is anyone not reporting issues, assuming someone else will? And what about that workaround you’ve become used to, knowing the devs are almost definitely going to resolve it any day now?

 

It’s worth questioning yourself as it’s easy to become over-reliant on Dogfooding. It’s no panacea, and no excuse for poor test coverage. Nor a reason to not have a thorough QA process. With it, beta testers are still going to throw up those big issues that leave you wondering just how you managed to use it and miss it!

So, yes, you should use your own products. But what you really want to do is use your own products like a customer. Better yet, use them like a new customer would.

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.

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 fogcreek.com 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 fogbugz.com, kilnhg.com, copilot.com or fogcreek.com 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.


Looking for more?

Visit the Archives or subscribe via RSS.