In 2000 Joel Spolsky wrote the famous Joel Test. Even if twelve years passed — an age in the computer history — I think most of his questions are still incredibly relevant nowadays. Let’s try to calculate the Joel Test score for weLaika, analysing our weak spots.

Do you use source control?

Yes! We use Git for every project, small or big, and all the team is aware of the extreme importance of the presence of a versioning system. Git has not the best UI in the world, but it’s so powerful, and so far we’re pretty much loving it. Maybe in another post we’ll share some of our workflows, shortcuts and aliases in detail.

Can you make a build in one step?

We should interpret this question more widely as: Can you build/deploy/upload in one step? We have different answers for this, depending on the target.

• With Rails projects we always use Capistrano, which is awesome;
• For WordPress websites we have specifically developed Wordmove, a nice little gem that wraps rsync to make the deployment as easy as writing a Movefile config file on the theme root directory. We’re pretty satisfied with it, and you’d be too, so go check it out;
• For mobile apps we’re still just using XCode/Eclipse to build our apps, so ie. things like OTA (Over The Air deployment for iOS) could be optimized and automated a lot more. We should experiment with tools like xcrun as soon as possible.

I’d give us half a point here.

Do you make daily builds?

Daily builds imply a CI server and a runnable test suite. For all the Rails web projects we make use of BDD, and we’ve recently setup a CI machine running CruiseControl.rb. Our open source projects also have a pretty decent test-coverage, too, and make use of the great Travis CI.

We don’t find useful to test our Wordpress works, mainly because they’re just views plus third-party plugins. If a website gets more difficult than that, we’d have used Rails.

Again, our weak spots are on the mobile development. Unit testing in Java and ObjC is definitely less fun, and integration/acceptance testing is a real pain. However, at least on iOS, BDD is definitely possible and we should investigate more here.

So again, I’d count this as half point.

Do you have a bug database?

Yes, we have Redmine for that and we love it! It’s our top organizational tool. We use it also as a wiki and project management tool.

To gather exceptions from our production state projects we make use of Errbit, a popular Airbrake open-source clone. Recently, we have also released an Android Errbit notifier.

Do you fix bugs before writing new code?

Yes, this is a policy that we usually take into consideration before developing, and it’s all true what Joel says about it.

Do you have an up-to-date schedule?

For long projects we use Redmine issues to track all the project. Weekly or bi-weekly we prioritize the tickets with our clients to update together the schedule. For small projects we usually don’t do it, but maybe we should try to experiment more on this. Communicate better and cleary with the client is always a good thing®.

Half point again.

Do you have a spec?

For small projects (less a man month), we usually write as much as possible before starting the project.

For complex projects, we make use of a two-steps process. We first write a rough spec with vague, worst-case time/cost estimates for the described features, just to give a quote to the customer without loosing too time upfront. If the first quote is approved, we spend the days of the project writing specs and mockups that are good for the customer and feasible in the given timeslot.

We’ve found this latter technique pretty useful for our works on contract. One catch that we should get better on, is to clearly define with the client the “definition of done”.

Usually in big projects specs tend to change during the development itself, so it then gets really difficult to define when the work has to be stopped and more money has to be injected.

Approaching the problem in a more agile way, using sprints to clearly expose to the client the initial uncertainty of estimates would automatically solve the problem, but we find incredibly difficult to apply this model on big projects; the client rarely accepts having any clue about the final price of the project. We still have to develop a good way to deal with this problem. Suggestions are welcome!

By now I’d count half a point.

Do programmers have quiet working conditions?

I’d say half also on this. We’re 5-6 people in a big war-room. That’s not the optimal choice, but it’s very cheap! We strongly encourage work at home when it’s possible, as we all know how hard is to get into the flow with external interruptions.

Do you use the best tools money can buy?

We try to stay free on the platform and every worker has a personal laptop that also use in his personal time. We don’t have official schedules to update them but we try to stay up-to-date with technology. We don’t usually encounter long compilation times, but that’s the case we have powerful desktop computers to do them. I think we are quite well on this.

One main problem is with mobile platforms: we should upgrade our mobile device equipment, mainly Android ones. We are working on that!

Do you have testers?

We find that using BDD and testing practices strongly decreases the need of a testing guy. On one of our biggest project, ThinkTag, we had one tester, and it has been our only tester so far. In general the project that we have are so fast or so tied with the customer that we don’t need them.

Do new candidates write code during their interview?

We are a very small company made of friends. The important rule to enter weLaika has been to share passion and will to take the enormous risk to start a company from scratch out of university. We are not planning to hire new developers soon, but in case we’ll obviously ask to write code! Extra points for open-source work, too.

Do you do hallway usability testing?

We don’t have a hallway but it’s usual for us to test each other the products before going on air. We usually let test the program to someone not involved in development, to get a more realistic idea. We are also planning to get a real usability testing on ThinkTag, our more long and lasting project where we are involved on the technical side.

Conclusion

weLaika now is rolling at 7.5 I’d say. I think it’s already a quite good result. The problem that I see now is that we are not at 7.5 on all projects and we should point at 12 in the next year on all feasible projects. I’m still not clear if going at 12 also on small projects is economically convenient. I’m thinking for example of small Wordpress sites or small mobile apps. What do you think?