80beans

Looking for Ruby developers

2011-12-13T12:57:00+00:00

We're looking for two developers to expand our team. We're open to considering both experienced developers and smart people starting out.

You'll be working in an experienced team building applications with our clients (mostly in Rails), ranging from early stage start-ups to publicly traded companies. We use a robust agile process, no death marches. We offer a great developer centric environment where you'll be able to continually learn both the technology and soft side of development. We provide an organic lunch, great hardware to work on and a ping pong table.

We have a few requirements:

You're located in or reasonably close to Amsterdam; we work at our office in the city center.
You're eager to learn.
You're comfortable communicating with clients in English, both in writing and verbally (it's okay if you're still learning Dutch).
You're happy working on Apple OS X, or willing to switch.
Bonus points for knowing a thing our two about front-end development.

To apply, e-mail us at info at 80beans dot com with a résumé and preferably a GitHub url. Feel free to indicate which code you're particularly proud of.

For an informal chat and to meet the team, drop by at one of our monthly Hack Nights.

ArrrCamp slides online

2011-10-08T14:38:01+00:00

ArrrrCamp 2011 was a blast. I had a great time thanks to Captain Joren, all speakers and attendees. My talk on front-end meta languages and the Rails 3.1 asset pipeline was well received by an almost full conference room.

I put the slides up on Speakerdeck, and embedded below.

Amsterdam Hack Night

2011-09-27T11:25:00+00:00

We're starting a monthly hack night! Every last Thursday evening of the month our office will be open for people who want to learn programming, bootstrap a project, hack on open-source or work on a hardware project.

At the start of the night we will gather all people's projects on a whiteboard, anybody who wants to help out somebody can pick a project to join.

The first hack night will take place at the 80beans office on the Vijzelstraat 72 in Amsterdam on Thursday, October 27th starting at 18:00. We will provide drinks and snacks. Please register here if you want to come. Hope to see you then!

ArrrrCamp, October 7

2011-09-02T15:37:00+00:00

On October 7, Roy will be giving a presentation on front-end meta languages and the Rails 3.1 asset pipeline at ArrrrCamp in Ghent. Tickets are still available and cost only €95, which apparently includes mojitos.

More info: http://arrrrcamp.be/

#rbxday at the 80beans office

2011-07-29T12:39:00+00:00

Next friday is #rbxday, A global day of testing of the alternative Ruby implementation Rubinius. 80beans will be hosting the Amsterdam location at our office.

If you feel like helping out you're welcome to join us. 80beans will provide refreshments.

This will take place at the 80beans office on the Vijzelstraat 72 in Amsterdam on Friday, Augusts 5th starting at 15:00. Please let us know if you're attending by placing a comment below.

Closed on June 2 & 3

2011-06-06T08:54:07+00:00

80beans will be closed on Thursday June 2 and Friday June 3 because of Ascension Day. For critical matters we're available by e-mail or on our mobiles.

Myth of the Flat Fee

2011-05-25T13:41:19+00:00

You made a deal with someone to build you a website. Best of all: you agreed on a flat fee! That's great, because you know you have a fixed budget. And you're getting everything you want, because that's what your vendor promised you. Guess what? It's not going to happen: your project will be more expensive than anticipated and/or will have less features. You fell for the Myth of the Flat Fee.

The Myth of the Flat Fee has most likely been around for centuries. You're definitely not the first one to fall prey to it. But why do clients keep falling for the Myth? Because you're looking for a sense of security when you're spending your budget on a web app. Vendors play along by providing this, albeit false, sense of security.

Any job we do at 80beans usually starts with a prospective client calling or mailing us with a request for proposal. Sometimes their information is detailed and well thought out, which gives us enough to work with to give a preliminary estimate. More often though it consists of one sheet of paper with a brief that comes down to "we would like a web app where visitors can keep track of X, with social media integration". We're then invited to ask questions, mostly being answered with something along the lines of "we don't really know yet" or "that's to be determined". That's fine. We love to work with you to find out what you want to achieve with your web app and how we can help you reach that goal.

But at this point you just want to know what it's going to cost you and if we can meet your deadline. After all, you have a certain budget you have to work with. And besides, the other development companies on the shortlist did offer you a proposal with a flat fee. If we want our proposal to be taken seriously, we should definitely name a price.

We then try to explain that we can't give an estimate, let alone a price, based on the supplied information. We'll invite you to first work with us so we know exactly what you want to achieve. Talk to us, join us in making wireframes/click demo's and writing user stories. You'll be surprised at the advancing insight you will develop while going through this process. There will be things you didn't think about, while some other essential features seem to be redundant. We can use the outcome of this process to base an estimate on, and it can be used by you to obtain more accurate proposals from others.

Every project consists of three attributes, also known as the "project triangle" or "triple constraint". There's scope: the features your app has. There's time: how long will it take to build your app. Finally there's cost. Changing one of those attributes will always have an effect on at least one other attribute. You might ask yourself: how can you determine the cost (and make sure it doesn't change) if the other attributes aren't entirely clear yet? You just nailed the core of the Myth.

So how can it be that those other companies can name a price after receiving your RFP? They can't. They're just guessing, based on the same limited amount of information we have to work with. Depending on how the scope of the project develops they will leverage other aspects. They will do so by engaging in Conflict Driven Development (CDD, a term coined by Thijs Cadier), either on purpose or because they genuinely assume they exactly know what you want.

During the initial phase of the project — when it becomes clear what you really want — they will say that's not how they interpreted the scope for some feature. Now you're faced with a few options. You can alter the scope so the cost remains exactly the same: the feature will be dropped, it will not be developed the way you wanted or you need to slim down the scope later on. Or you can decide to pay more to get what you wanted in the first place. There the flat fee goes out of the window. A few weeks later the same situation occurs. First there's a conflict, then there's choosing between building something you don't really want, or paying more.

In either case you won't be happy. All those conflicts drain energy, require a lot of project management and lead to a disappointing and/or unexpectedly expensive project. You have a very weak position in negotiations, since you already invested time and money in the project when the conflicts start occurring (or worse: a hard deadline is approaching). It's an investment you don't want to see go down the drain.

At 80beans we take a different approach. We understand that your budget is important to you and that you don't like surprises. Just tell us what your budget is and we will have a chat about what we can do within limits. Let's write user stories and prioritize them, so we know we start with the most important ones ("must have"). We're comfortable with guaranteeing that we can develop the stories you defined as "must have" within a certain budget. The other, less important stories will be developed last. That way you get all the essentials and a large part (or possibly all) of the rest of the stories. During the development process you can keep prioritizing the stories, making sure we build you a great app within budget. If too many stories become essential we might need to go over budget, but at least you know and can make an informed decision instead of being faced with a conflict.

Sometimes clients end up working with us after initially choosing another company. We then iterate on the work that has already been done. When we find out the price a client paid in the end, we're often confident we could have done at least the same job for the same amount of money. Without all the conflict and at a higher level of quality. The problem we often encounter is that prospective clients find out the hard way. We'd love to hear any suggestions on how we can improve our communication in making prospective clients understand early on.

Bottom line: we're not more expensive than others, just because we won't give you an estimate until we're confident that we understand your needs. We just choose to avoid conflict and build you a kick-ass web app.

Tapir, a static website search engine

2011-05-18T14:42:30+00:00

A few weeks ago Jeff came up with the idea for a search engine for static sites (like his own). Together with Robert & Ivana (who designed the logo) Tapir was developed. It indexes your blog posts based on an RSS-feed. The index can be searched using a simple API. Together with Robert I wrote a jQuery plugin that makes it even easier to implement.

The project is sponsored by 80beans. Part of the development was done in company time and we provide hosting resources.

Your idea is worthless

2011-03-29T08:50:00+00:00

Alternative titles for this post could have been "Execution is everything", "Your idea isn't unique" or "Why we won't sign your NDA".

Yes, the subject is a dead horse. A lot has been written about it and we often point people contacting us to articles by VC's and industry leaders to try to explain people why we won't sign their NDA. Based on those articles and our own experience I'll try to explain why your idea isn't worth much and why we would soon be out of business if we signed NDA's everytime someone asked us to. This way we can declare this post "company policy" and you don't have to go around reading others opinions, although we still encourage you to do so.

Please note that most of this post applies to people who want us to invest in their yet nonexistent company, or want to have an application developed based solely on an idea and some rough sketches. Of course we have a clause in our standard agreement that states we will treat everything you tell us as confidential, and we tend to bring this this agreement to the table in a fairly early stage. For some that isn't enough.

So what's an NDA?

I'm pretty sure you know, but for completeness sake: a Non Disclosure Agreement is a contract you want someone to sign before you let them in on your idea, so they don't run off and steal it from you. In its simplest form it will make us treat whatever you are going to tell you as confidential and we'll agree to pay a certain amount of money in case we don't. NDA's can range from anywhere between a single page and a lot more than that (I once respectfully declined to read, let alone sign, one of 50+ pages).

Why would you want us to sign one?

99% of the time: because you think you have a great idea (which could very well be the case) and you're afraid that by telling someone it may get stolen (or better: be executed by someone else). You may not know us well enough to just take our word for it. If we run off with your idea you at least want us to pay that 50,000 euro penalty and have us turn over any revenues. There are exceptions, for instance because you're working under embargo of another party, but I'm ignoring those edge cases for sake of simplicity.

Your idea is worthless

I'm sorry to be the one to inform you, but your idea is worth pennies. You don't get rich over an idea. Apple doesn't make billions a year because people pay for Steve's vision of a tablet device. Execution is what counts, what makes money and brings value to the table.

Your idea is not unique

Pretty much any idea that has the potential of actually being executed is not unique. You're not the first one to cook it up, many before you have thought about a web app that can do X. Our ideas are always based on other ideas. We only think of a web app that can do X because others paved the road before us, created a market, etc. Facebook wouldn't have been executed if it wasn't for the different face books floating around at Harvard, which made multiple people think about developing a Facebook-like application.

We would soon be out of business by signing NDA's

Lets put it all together. You have a great idea for a social networking site for <insert niche> that integrates with Facebook and Twitter. You have though about it for a while and came up with a brilliant business plan. The only problem: you have no money. No worries, because you have read about our Startup Program. You set up a meeting, tell us the above and ask us to sign an NDA. At the point where we haven't even discussed working together yet and we have no idea what your idea is. Chances are pretty good that we won't be teaming up in the end. But, for sake of this argument, we'll sign your piece of paper. After disclosing your idea we believe there is no money to be made based on your business plan, so we part ways.

A month later someone drops by who has an idea for a social network for <insert different niche> that integrates with Facebook and Twitter. It makes sense, can be developed in a reasonable amount of time and it looks like it will be profitable after only a few months. Lets do it! But wait... we can't. If we do so you can sue us because of the NDA we signed.

You gain from sharing your idea

Every time you tell someone your idea they will voice their opinion. That's great, because it allows you to keep sharpening your idea based on the opinions of real people instead of the voice in your head. If you tell us your idea and we don't end up working together, I'm sure you won't regret coming over. We will make you think about the little things you didn't think about, let you know which parts of your idea are really good and assess your business model based on our own experiences. And all of this you get for free, just because you let us or anybody else in on your idea.

Bottom line

If we would have signed NDA's every time someone asked us to, all with a scope as broad as most of them, we could never build a web application again. We would always be violating some NDA.

So you're asking us to sign an NDA that forces us to pay an insane amount of money if we execute your idea (which has little to no value lacking proper execution), or if we build any application that falls within the broad spectrum you defined in the NDA. We will of course keep whatever non-generic information you disclose to ourselves, and we're willing to promise you that in writing. If that's not enough for you to trust us with your idea, you better keep it to yourself.

Slides for my presentation at Fronteers

2011-03-04T08:27:00+00:00

Yesterday we organized a Fronteers-meetup where roughly 60 people attended. Vasilis van Gemert had a great talk about adaptive design using media queries and I spoke about front-end meta languages like Haml, Sass (+ Compass) and CoffeeScript. The slides are now up on SlideShare.

Also a correction: I was wrong when I said you couldn't use CoffeeScript inside your Haml. There's a custom :coffee filter that works just like the :javascript filter. I didn't know because it doesn't come bundled with Haml. It seems like it will only work in your Rails apps though. I was also wrong on Sass within Haml, since there is a :sass filter that comes bundled with Haml (no need to install anything for this one).

Not mentioned on my slides, so here are some links: Haml, Sass, Compass & CoffeeScript.