Futurice is a company with a flat hierarchy and everyone having lots of power to decide things. However, this comes with the responsibility. If you want to get something specific done, you don't go bother the boss or, in the case of bigger things, the boss's boss, to get a rubber stamp for the decisions they have no clear idea about, like in several traditional companies. The point is that you decide. With that comes the responsibility to make a good decision, and involving other relevant people in your decision making process as needed.

Of course, the responsibility part can sometimes be tricky: is it ok if I buy a piece of software that costs 1000 €, or is it not? Small things are usually not a problem, but what about bigger or more complicated decisions potentially affecting a greater number of people?

There are not and cannot be any good and fixed rules in a changing environment like ours. Thus, we drafted not a set of rules nor guidelines, but a short piece of support material about what would be good practices for decision making in Futurice. Creating this material, of course, has followed the way presented in it: practise as you preach, like the saying goes.

Principles: everyone has the decision making power, and the obligation to make good, transparent and fair decisions. The decisions have to be evaluated agains our 3x2 framework, that is, taking the people, customers, and numbers into account now and in the future.

Check out the attached presentation for the main points, more details and sample cases.

Futurice_Decision_Making.pdf Download this file

Permalink | Leave a comment  »

Understanding maintainability is hugely important for any maintenance team. Although the financial affect of bad maintainability is difficult to estimate, it is clear that maintenance problems will cause significant increases in the development costs after the product is released. In this post, I will shortly discuss how maintainability is built and give some instructions for developers. 

Traditionally people tend to think that maintenance is just fixing problems when they occur. In reality, at least in our experience, most of the maintenance effort goes into adding new features. Therefore, better maintainability is not just about fixing problems faster and easier, but also about adding to the business value of the product with smaller investments.

Maintainability is a notoriously difficult to define. One can find numerous different definitions for it in the literature, but none of them have been commonly agreed upon. In fact, I argue that there cannot be a definition that is both conclusive and measurable at the same time.  This is because maintainability has a hint of subjectivity in its very core.

Most common form for the definition of maintainability is quite simply “the ease of maintenance”. It’s actually very intuitive – almost a self-evident. The problem here is that we cannot objectively measure the ease of something so complex. It depends highly on the developer’s base knowledge, her experience in specific technologies, her understanding of the project, and the company culture.

So, why should we measure something that is difficult to set in mathematical form? It’s widely believed that one cannot control what one cannot measure. And, in a way, this is undoubtedly true. There are also many situations when it would be important to estimate how difficult a product is to maintain, before a developer is assigned to do the maintenance.

Luckily, there are plenty of sub-factors in maintainability that can be measured. Many researchers have suggested measurements for maintainability that are based on estimations of the sub-factors. The problem with this approach is that it doesn’t cover maintainability fully and does not reveal the underlying reasons when maintainability is compromised. One can spend a lifetime trying to find a perfect formula for maintainability, but never get anywhere with it. 

As complex is the problem of measuring maintainability, as easy and intuitive is the workaround. To improve maintainability you do not improve maintainability. Not as a whole. Instead, you split the problem into smaller pieces, find the sub-factors that cause the maintainability challenges, and improve each aspect one by one.

So, what are the sub-factors of maintainability? Numerous books have been written on the subject and it is not meaningful to list all the factors here. The main goal is to keep the source code readable, the structure intuitive, the test coverage high and documentation up-to-date. For more concrete ideas I recommend such books as “Clean Code” by Robert Martin or “Working Effectively With Legacy Code” by Michael Feathers. There are, of course, a lot of other great titles as well.

In the beginning of this post, I promised a few instructions. Before we get to them, I must warn you: as maintainability is not an exact science, I cannot give you concrete instructions. You have to adapt them to each project separately. And don’t just decide how you apply the instructions – also consider how you can measure and follow your progress during the project.

Consider maintenance from the beginning. Each technical decision affects the maintainability of a project. The longer it takes to correct bad decisions, the harder it becomes to get rid of the problems. Maintainability cannot be built into a project afterwards.

Define and monitor “done”. Definition of done is a well-known tool in the industry. But don’t make your DoD just a list of good practices. Define it so that you can follow it literally. This way it becomes more than just a guideline.

Automate processes. Scripts are handy when you have constantly re-occurring tasks. In fact, that’s what programming is all about. So automate your test routines, deployments and other must-have processes.

Share and store knowledge. Communication is the key to a successful software project. Understand the customer, understand other vendors and understand your colleagues. And once you have gathered the knowledge, store it in documentation. It’s very important for the maintenance team.

Test the code. Do I really have to emphasize this? Probably not. Just two things to say: try to break, not confirm, the program with your tests. And make the tests meaningful. 

Refactor while making modifications. You are most familiar with a module when you are making a corrective or an incremental change. This is a good time to investigate if the structure of the module is up-to-date or not. If it’s not, refactor it.

Permalink | Leave a comment  »

We just released a new version of our public status information! Our previous version was a Pingdom public status page (available at old.status.futurice.com), but we ended up wanting to share more – and, of course, it should be faster and look better. We truly believe transparency brings shitloads of good, and this is yet another way to show it. For example, do you want to know what is the status of our printers? Or number of tickets IT team handled?

The new version uses many new technologies to make it better: application cache for instant page loads and offline usage, localStorage for faster page loads and storing data for offline usage, EventSource for instant updates when new data is available, web notifications for alerts, good looking charts using SVG canvas. Not everything works in every browser, but SVG support is the only mandatory part (and site works without that, just without charts). All the data is stored in Redis, which provides a very fast and persistent in-memory database.

There isn't any reason to not to release the source code, so here you have it. It's licensed under the MIT license, and the license document lists licenses of other components included in the repository. Unfortunately, due to the nature of the site, installation is rather complicated. Installation steps are outlined here. Feel free to use, fork and improve.

Permalink | Leave a comment  »

Next week, it's time to try to negotiate a contract with one of our customers. We have already worked with this customer already for several months without one. It is entirely possible that we will continue working without a contract after the meeting.

A great amount of trust is needed when working in a contractless state. The process is very simple: The client requests our work, we do the work, we send the bill, they pay it. But the customer needs to trust that we will be there to help them, that we will do high quality work and that we will not overcharge them. We need to trust that the customer won't abuse us and we need to trust them to pay the bills. It takes time to create trust like this, and it can easily be lost. Yet, curiously, a contractless state is neither an improbable result nor is it a huge problem for us and our customers. In fact, approximately 50% of our monthly revenue comes from customers who we don't have a contract with.

While "Customer collaboration over contract negotiation" is one of the values of the agile manifesto, having no contract at all is a somewhat extreme situation to be in. What if two customers are having a crisis simultaneously? Who gets the most attention? How much convenience will we sacrifice when planning vacations if we have no obligations to provide any response times? How can we plan our revenue stream and resourcing if we have no agreement on the work needed? There are several good reasons to have a contract, so why do we so often end up working without one?

Every project is different, but in general the sequence of events goes something like this: initially, the delivery project is negotiated and what happens after production deployment does not get much attention. It is something that can be negotiated later on, as long as there is a promise that post-production support will be available. Then, after the always hectic deployment, the customer cuts down investment, and the majority of the team can no longer stay with the project. If the development bandwidth gets constricted enough, we reach the moment when it makes sense for Lifecycle Management to take over.

Negotiating the terms of post-production development takes its time. Yet, some changes or new improvements need to be done ASAP, so we usually end up doing them before a contract is agreed on. There is initial trust in place, carried over from the development project. And the longer the contract negotiations take, the more trust gets built up from our work and the more the contract starts to look like a detriment to the current situation. We have now created a situation where the development goes on, and agreeing on a contract has become both unlikely and even to some extent unnecessary.

What makes finding a good contract model for software maintenance so difficult? There are several reasons for this, but at least for us, the most important ones are the service level agreement (SLA) and other contractual issues that involve sanctions.

The purpose of sanctions is to affect the behaviour of the participants in a contract. The unintended side-effect is that unless the sanctions are negligible, they introduce so much risk in the business that avoiding the sanctions becomes the primary driver in any future work. This overrides generally beneficial values like collaboration and efficiency, as the risk becomes factored into work estimates and prices. The ability of a team to be agile erodes when all actions need to be planned from the perspective of not getting hit by a big stick.

A good agile maintenance contract should facilitate, not dictate. It should set the stage for co-operation, define goals and trust the participants on both sides to find the best route to reach the goals. It should secure both the customer and the vendor against disasters but avoid obsessing over smaller inconveniences. Applying contractual sticks or carrots endangers co-operation and should be avoided whenever possible, preferring more subtle guidance.

Is a contract necessary for agile maintenance? The evaluation of the need is a complex function of trust, corporate policies, pricing and consequences of a major failure in service availability. Some of our cases do well without a contract and neither side wants one. Some of our cases have a good contract that facilitates the work. With some cases we would like to find a contract but are not able to agree on one that wouldn't hurt the status quo, so we continue without one.

This is the third installment in our series covering an experimental agile maintenance concept at Futurice. Previous installments: Re-inventing custom software maintenance by Teemu. Selling a concept for agile maintenance by Rauli.

Permalink | Leave a comment  »

Last week, Teemu wrote about the need and concept that gave birth to Lifecycle Management here at Futurice. I'm going to continue on the topic and discuss the basic public relations challenges we face with the concept.

Let's start with a quick question. How do you feel about software maintenance? If you are a software developer, odds are that you don't think very highly of it. Indeed, the reputation is terrible. Unmotivated and/or unskilled coders, wasting away in a career dead-end position. Low-skill work, lots of tickets, instruction manuals and unhappy customers. Right?

If you are a software buyer, odds are that you don't think too highly of maintenance departments either. You've probably read and signed ambitious Service Level Agreements (SLAs) and decided upon detailed pricing models. You might have discovered that the mandated response time is fulfilled by an email auto-reply and not when the actual work on the ticket starts. Sometimes you even have to convince the vendor that the problem is in their domain, and the burden of proof lies with you. This gets especially bad in multi-vendor environments, where vendors like to point at each other instead of finding out the cause of the problem.

To make things worse, a typical pricing model for solving a problem ticket encourages the vendor to employ resources that don't solve the problem too quickly. It is bad business to solve a problem in 45 minutes, if it can be solved in 8 hours to get 8 times the money. I've lately started to suspect that defining a software maintenance contract that improves the service provided is as difficult as defining good personal bonus criterias. The challenge of defining a good contract is an interesting topic and I will write more about it later.

Bringing superior service to a technological field, where bad service by low-cost personnel is the de facto industry standard, sounds relatively simple on paper. Just do the job well and bring value to the customer, right? Not so, in our experience. First, you need to convince skilled and motivated people to provide the service. After that, you also need to sell the idea to the customer. This is where we need to shape the expectations brought by the heavy maintenance stigma.

Recruitment is difficult. Well, recruitment is always difficult, but recruiting talented people into a software maintenance and post-production development organisation is especially so. Try asking any developer if they would like to work in an organisation related to maintenance. They are likely to run away before you finish the sentence. Internal transfers from other teams to our team do not really happen, either. For anyone uninitiated with our concept, a transfer to our team would feel like a demotion. It is not going to happen voluntarily, and mandating such moves would be a very effective way to destroy motivation and make people quit.

Taking the time to explain our concept effectively to the candidate pays off when recruiting. After that, it becomes evident that the job is a challenging one and it offers opportunities for professional development. We want our people to be customer-oriented technology generalists, who are able to understand the customers business well and learn new technologies quickly.

While this sets the bar quite high, our promise for the recruits is equally bold:

1. Nobody works alone on a service.
2. You can get as much customer responsibility as you like.
3. You get to participate in pre-production development projects if you want to.
4. There are no internal fences here. If you don't like working in our team, you can join another one.

The promise has so far been largely kept. Currently, we have two people participating in long term pre-production development projects and some participating in shorter projects. People have worked alone in projects for some periods of time, but these have always been periods of very low activity in the project. Customer responsibility is always there for the taking. We haven't had to test the fourth promise yet. We see this as an encouraging sign and a success in building a team with an identity.

The perception of customers is another challenge. It is difficult enough to sell a "better model" for maintenance and post-production development. When the perception is that the maintenance department is mostly able to answer the phone and follow pre-made instructions, it is hard to convince the customer that we actually have competent, senior developers at their disposal. Sometimes it even seems difficult to sell the idea that our organisation would actually be able to do any post-production development. Not long ago, a customer described their need to be exactly what we offer: active small-scale post-production development that would, in itself, take care of the software maintenance needs. They just couldn't believe that it could be done by a 'maintenance' organisation. The traditional split between development and maintenance organisations is heavily ingrained indeed.

We are still searching for the right ways to sell our service to customers. Different purchasers from different organisations value different things. Some value detailed SLA:s, some value direct communication with a known person. Some value ease of buying. Some will think of any post-production activity as a mandatory evil which should be avoided if possible. Selling continuous post-production development will sound to many as an ambitious maintenance department that has forgotten its place - which, to be fair, is a view that in some cases holds a grain of truth in it. If the software in question is not an essential part of the customers business, it doesn't make much sense to make an ambitious maintenance and post-production development plan for it. When we recognise these situations, we strongly recommend bringing in a third party for the maintenance.

For us, continuous development is the whole point. We believe that there is no better way to retain and increase the knowledge of a system than working on it. There is no better way to do post-production development than doing it continuously, keeping the knowledge of the system fresh all the time. There is no other way to keep an experienced developer motivated to tend the system than continuously working on it and being able to produce quality. If we believe that the business case does not enable us to do this, then the case is not for us. But when first class post-production development is needed quickly and economically, our way is a proven way to do it.

Permalink | Leave a comment  »

Traditional concepts for software maintenance applied to custom software have resulted in unmotivated teams serving indifferent or unhappy customers. This presents the polar opposite of what Futurice aspires to be and do.

I don't want to write about the traditional models, so I won't! There is plenty of literature available on the subject, check out Amazon. 

We needed a fresh concept. Since I had personally failed twice before to come up with anything substantially better, I hesitated in volunteering. The environment at Futurice was (and remains) unique, though, with mutual respect and low hierarchy; game on.

Having a technical background, I really like numbered lists. Hence, some axioms to base the new concept on, based on experience:

1. Maintaining and improving complex custom software is damn challenging.
2. A sense of ownership is important; traditional handovers never convey that.
3. Systems usually start to generate revenue at launch – this is the real test.
4. The needs of the customers are seldom alike.
5. There is always technical debt; it's about how you manage it.
6. Mentioning 'maintenance' turns ambitious jobseekers sad.

A logical first step was to talk with the people who were doing the maintenance here. What works? Not much. What disturbs you? Everything, pretty much.

To brazenly summarize a series of long, thoughtful discussions, the main issues were identified as:

1. Doing erratic ad-hoc work instead of organized and planned development
2. Less than optimal maintainability of the systems being maintained
3. Lousy image of the work, it being "just maintenance"

There were also some issues with customer satisfaction and profitability. Nothing really bad, but we set the bar impossibly high here at Futurice.

For evidence, behold our new unit's goals for its first year of operation:

1. Top employee satisfaction
2. Top customer satisfaction
3. High profitability despite growth

How's that for ambition? Yes, they are in order of importance.

We had identified the main six generic challenges, the three biggest issues voiced by the people doing the work currently, and now we also had ludicrous goals that I promptly communicated up, to the amusement of the CEO and the board.

Now, the new concept. It had to be simple for it to work. Again, what followed was a series of long discussions, scribbling on whiteboards, finding out what was written on the subject of agile maintenance (not much). Even some beer may have been had. 
 
Here's the nine-step team recipe we came up with, if you want to give it a try:

1. Come up with a flamboyant name that does not include the word "maintenance". We went with Lifecycle Management, so please call your unit something else.

2. Recruit (internally and externally) a quality-focused team of developers. Make sure to include some people that are in the early stages of their career, but balance it off by having enough benevolent seniority. Having one or two people generally acknowledged as badass professionals to join from the start is beneficial.
 
3. Focus on service improvement instead of bug-fixing. Your primary goal is to help the customer get more out of the system they have ordered. Succeeding in this has a positive side-effect of preventing the post-production development from being marginalized. We want to improve the services and invoice the actual work we do. If we can do this, there's no need to ask for any compensation for fast response times. Or to bother the legal departments with strict SLAs, really. Mutual trust is the key.

4. Have your team members participate in the development projects to ensure quality and maintainability. They will learn about the solutions being built and can elegantly carry them to the maintenance phase. Handover averted. Sense of ownership achieved. Technical debt decreased. If this is not possible, and the solution is very complex, steal people from the project team for at
least a couple months. If they are stars, never let them leave... by making sure they want to stay!

5. Develop an ambitious roadmap. In a project house you are a logical internal services provider - services such as testing, auditing, coaching and so forth. Instead of being the Maintenance Unit, you should be aiming at becoming the Services Unit. In addition to helping your company, this will open up all sorts of fascinating career development opportunities for the team.
 
6. Make sure you are profitable. This is easy if your project teams generate high quality solutions, so that warranty fixes do not come into play and generate overruns. Productize your offering in order to make buying easy. Remember that customers have very variable needs; be flexible, but remember you are running a business.
 
7. Grant people a lot of responsibility. We have a service manager role; this is usually a software engineer acting as a constant point of contact to the customer, while simultaneously improving their solution - the lack of overhead is refreshing for all parties involved. Having the lead developer learning the customer’s business by heart is invaluable.
 
8. Perhaps needless to state, but keep the concept and your operation model under critical evaluation all the time - never stop improving. Ask for customer feedback and if that is not enough, demand it. You need it.

9. Keep everyone in the team involved in developing your new concept and way of working. Also invite people from other units and upper management constantly to contribute and review your offering. The best way to get people to understand the value of what you are building is to have them participate in the design.
 
Our unit has operated fifteen months now. We have grown from the initial mini-team to a respectable unit, and we are currently the fastest growing unit in the company. Our customer satisfaction is high, our employee satisfaction is high and we are quite profitable indeed. We are enjoying the work and meeting the targets.
 
Certainly there is room for improvement and this is precisely what we plan to do. We will author some more posts in the coming weeks, discussing the challenges, characteristics and opportunities of this business in detail. I am sure our thoughts about DevOps will be included.

Permalink | Leave a comment  »

Believe it or not, coding was a hot topic at Interactions 12, the Interaction Design conference of the year. Ryan Betts talked about code literacy and its importance for Interaction Designers, Jonas Löwgren reminded us that coding is in certain cases an indispensable sketching tool, and the general agreement was along the lines of coding is cool, learn it, don’t be scared of it. 

It was a healthy attitude, and I couldn’t agree more about the importance of code literacy for designers: code is the material that our designs are built with, and a solid understanding of it not only makes our developer friends like us, but simply makes our designs better. 

But understanding code to some degree is one thing, and using it in daily work is another. When thinking about the work we do in our projects at Futurice, I realized that we, the designers, (almost) never code. I started asking myself: is it enough to reach some level of literacy, or are there situations when we should also be coding ourselves? If so, what are they? In other words, “To code or not to code?”

First, let’s look at the situations when we would need to code.

Good enough skills

If your skills with a technology are good enough that it’s faster for you to code the UI yourself rather than to specify it and for the developer to code it, then why not code? It might be even fun for a while (until you run into the first hurdle).

In quite a few projects at Futurice, I have been doing big parts of the CSS coding myself because I felt it would be faster this way than handing over a spec file for it. Whether it was actually faster is a different question, but that’s something that each of us can judge for themselves. Beware, though! When you start coding, you have less time for design, and there’s a risk it will suffer. Especially if you have a tight schedule and quick iterations, you might want to stick to your side just so that it gets enough attention.

No developers

If you’re working in a design agency and developers are scarce, I imagine any coding skills will be extremely valuable. In some cases, making clickable prototypes may be more useful than static screens and flow diagrams, and coding can still take you further than most prototyping tools out there (with greater effort, though). I don’t have any personal experience in a design-only agency though, so I won’t say more about this.

Uncharted terrain, fine-tuned interactions

There may be projects where you’re trying something completely new, in terms of how certain interactions should happen. Either you’re trying new forms of interaction, or you have a situation where you need to fine-tune the details a lot until you get a satisfying result. Because it’s uncharted terrain, it’s hard to get an idea of what you want from existing references, and it may be impossible to prototype it without code. 

These were a few situations I found where coding might be appropriate. How about reasons not to code, then? I’ll look at those next.

Straightforward interactions

Most of our projects are pretty straightforward, from the point of view of interaction and UI patterns we need to use. I see ‘code as a sketching/prototyping tool’ more useful when exploring new forms of interaction, or when prototyping interactions that would otherwise be impossible to prototype. But in many of our day-to-day projects, the interactions to use are more or less standard and easy to reference, so it’s relatively easy to get an idea of the desired outcome without having to code it first. And when we know what we want, we can just say it or show it to the developer in the team.

Developers are (much) faster

I was recently in a project that was a bit different from our usual projects, in that it was a lot about transitions, synchronizations, and telling a story through time. Many small fine-tunings were needed, and one could argue that this would have been a perfect occasion for me to make the adjustments myself and to get exactly what I wanted. But this would have been so time inefficient! Being such experts in the technology used, the developers were much more prepared to try any changes on the fly, and all we needed to do was to sit down together and fix the things that needed to be fixed. The going would have been so much slower had I started to learn the technology at that point!

Sketching mood

Design is a lot about sketching (as in trying things out quickly to see what happens), and in order to keep that sketching mood going, our tools need to keep a low profile. If we want to keep any kind of flow in our work, it needs to be “what if this were here and did that?” and not “how do I get this to be here and to do that?”

It’s easy to sketch with pen and paper: you just draw it, and it’s there. After some years of experience, it’s pretty easy to sketch with Photoshop too: you drag stuff around, you hit some keys to make adjustments, and the feedback is pretty immediate. With coding, the story changes (at least for me). You write stuff in a separate window and then check what came out, and then write stuff again, and so on. The feedback loop is much longer. Plus, we’ll easily get stuck in code and forget why we were doing something, instead of just experimenting continuously to get our answers. (If you want to see an excellent example of what coding with immediate feedback is like, watch Bret Victor's Inventing on Principle)

So far I’ve argued both for and against designers coding in their work, depending on the context. But is there an option somewhere in-between? I’ll look at that next.

Middle-ground

There could be one reason to come out of our comfort zone and meet the developers halfway; and again it has to do with doing things faster. The question is this: if I said earlier that developers are faster than us in playing around with the (UI) code we care so much about, is there a way that we could get that outcome just as fast or even faster? Sure, if only Photoshop exported working code…

So then, to rephrase: would it help make things faster if we had tools that were similar to Photoshop (as in point and drag), but were tied directly into the UI code that the developers work with? As a “compromise”, we’d have to deal more directly with the code constraints, but still we wouldn’t be messing with the code itself (unless we really wanted to ;). 

That brings us to WYSIWYG editors. These kinds of coding aids have been around for some time, but in my view only now they’re finally becoming good enough to be used for this purpose. Lately I’ve been playing around with Microsoft Blend for Windows Phone 7, and I found it quite promising. After some frustrations at the start, you start learning you can drag things around and experiment with the layout, and then all the really cool things: behaviors, styles, transitions, mock data… And then it suddenly becomes fun, because you realize just how far you can get without writing any code. And of course, once you’re done making the layouts and specifying interactivity and transitions and all, the developer can just take it from there!

There is still the question of “sketching mood”, though: can we reach a level of proficiency that allows us to easily play around with things, and not get stuck in the tool? I found this a bit challenging in the beginning, when I was trying to do things “the right way”, but when I just started doing things “the fast way” to begin with, and worry about the right way later, I found that I was able to get into the flow pretty well. Even though it won’t happen overnight, we believe we could get familiar enough with these kinds of tools, and the payoff would be pretty good!

To summarize, here’s a prospective answer to the question I began with.

Code when:

• You’re good enough that the time it takes you to do it is less than the time it takes for you to communicate it and the developer to do it
• There are no developers to help you out
• You’re on uncharted terrain: trying out new interactions, trying out concepts that can’t be prototyped without coding

Don’t code when:

• Expert developers in the team can make adjustments while you speak
• There are easy enough ways to communicate interactions and transitions
• Familiar, predictable interactions; developers speak UX, can easily understand what you mean

Middle ground:

• If there is a middle-ground tool that gives enough flexibility to you and clean, working code to the developers, consider using it.

So, how about you? How literate are you with code, how literate would you like to be, and when do you think coding would be useful? It would be great to hear your opinions!

Permalink | Leave a comment  »

Windows 8 has been something of a hot potato since the developer preview was released half a year ago. It introduced some rather controversial changes to the cozy operating system most of us have grown up with. Two weeks ago the consumer preview was released, revealing the major changes to a wider audience, and the blogosphere has been totally crazy ever since - both for and against. With yesterday's rumor of a Nokia tablet (presumably running Windows 8) due later this year, we decided it was time to gather an overview of the situation.

We've done some Windows 8 stuff already, and you may have read Timo Tuominen's excellent peek into HTML5 on Windows 8, but we (that is, my esteemed colleague Mr. Timo Hyväoja and myself) thought there's a need for a broader overview on why we think Windows 8 will be a big deal and how you can get on board. So Timo dug up some unused pieces of hardware and installed the consumer preview, and I started skimming through blogs and grilling Timo with all kinds of funny questions. This is where we got so far:

Why is Windows 8 such a big deal?

Cynical answer: because it's Windows. :)

Since we're not all that into being cynical here at Futurice, allow me to introduce a couple of other points:

• There's a whole lot of Windows machines out there. Soon many of them will be running Windows 8. This is more a question of when rather than if (read: "Because it's Windows").
• Windows Phone is showing promising signs that consumers like the new Metro style that Windows 8 now introduces in 'heavier' devices.
• Besides good ol' x86 hardware seen on desktops and laptops, Windows will now run on ARM hardware - i.e. tablets/slates optimized for mobile use. Recent news about the Windows Phone 8 sharing the same kernel with Windows 8 suggest that the device coverage is not going to decrease...
• Windows Store will bring totally new revenue possibilities for Windows developers, and there are a lot of them.

So, if Windows has been the operating system for desktops and laptops, it is very likely it will be the operating system for all online devices soon. Enough to get your attention? Read on.

What's new?

Windows 8 comes with a number of cool changes, but below we've listed a couple we're really excited about:

Metro changes the way people do stuff on their desktops

The most apparent change of course is the new Metro style with its start screen and tiles that replace the old desktop with the Start button:

You might've already seen the Metro style creep into your Zune player or Xbox 360, but it was really widely introduced with Windows Phone. Guess what? Soon it will be your desktop experience everywhere. While Metro has received mostly good feedback on Windows Phone, on desktop/laptop it has raised quite a lot of concerns - will it scale to easily accommodate all your apps, will you ever get used to the horizontal scrolling with your mouse, and, let's not forget, where's the damn Start button? While admittedly there are some issues left with non-touch devices, we think this is mostly just an initial shock reaction - just like with Windows Vista, it's not all that trivial to successfully get people used to a major change with such a large user base.

ARM support introduces Windows to a lot of (new) hardware

So Metro changes what is shown on the outside. While this is the major change for most consumers, possibly a far more significant change is under the hood: Windows 8 basically means that the ARM processor architecture is now supported besides the standard x86 architecture. This means more affordable hardware and better battery life among other things, both very welcome in mobile surroundings - and with affordable slate (that's 'tablet' in microsoftese) hardware, we're going to be seeing a lot of mobile Windows hardware out there. There are a couple of gotchas and caveats though (see Things to consider, below) but overall this means that the same app will run on a lot of hardware. No wonder it's dubbed WOA! (That's short for Windows on ARM.)

Windows Store brings a whole new software ecosystem to your desktop

In the wake of Apple's App Store et al., Microsoft is jumping on the app bandwagon. Just like Mac App Store brought online app shopping to desktop, Microsoft Store will bring the super-easy app purchasing process to PCs. Microsoft will take a 30 % share of your revenues (or 20 % if your app is selling big) but you won't have to worry about payments, regional taxes or any of the sort - just collect the money. What's different from, say, the Apple App Store is that for in-app purchases you can either use your own payment methods or the Microsoft Store APIs. This might turn out to be an interesting revenue stream for developers... And what's more, developing apps is now easier than ever with HTML5 (see below).

How do you create apps for Windows 8?

Easy, set up the SDK and fire away:

As has been the case for a long time, Microsoft development tools are top notch and getting up to speed with development is a breeze. Truth be told, there are still a couple of wrinkles left (especially with Expression Blend, which is used to facilitate designing Metro user interfaces), so there is still work left to be done for the fine people of Redmond, but you would be surprised how fast it is to get started with Windows 8 development.

What's big about Windows 8 is that it introduces a totally new development paradigm that expands the developer community by hordes: in exposing the system to HTML5 + CSS3 + JS via the new WinRT APIs, Microsoft is giving access to native application development for legions of web developers - and this means real desktop applications in the Metro style, not just web stuff. Check out Timo Tuominen's post on Metro on Windows 8 with "Native HTML5" for an quick review. For those not in the know, this essentially just means that application development will be even more streamlined and requires less specialized skills from the developer - in other words, more productivity and shorter time to market.

Besides the new HTML5 + CSS3 + JS path, you can of course develop your app in the tried and tested VB/C#/C++ and XAML way. One thing to say goodbye to, however, is XNA. Developing games, for example, (or anything with heavy graphics) happens now with DirectX - and you have to do it with C++. This is a nuisance to developers who have spent a lot of time on learning XNA, but in the end it should be for the better. Time will tell.

How to distribute the apps, then?

Once your application is ready, though, there's one more proverbial dragon to slay: the distribution. You can of course do it da old skool way and just put your app on your website (or wrap it in a cardboard box if you prefer such antiquities), but if you want to do cool new Metro stuff, or if you want to deploy on Windows tablets, the Microsoft Store is the only route. Get it? The only way to Windows tablets is through the Microsoft Store. This means that your software will have to conform to the Microsoft guidelines, but luckily they are very sensible and for the user's benefit, even if they are a little on the strict side.

Things to consider

We think Windows 8 will be a huge opportunity for software business, but most of all, it will ultimately bring desktop and mobile developers closer together, benefiting everyone. There are a couple of things to watch out for, though:

• You will have to redesign and redevelop for Metro. If you have an existing concept, it will have to be thought through with a totally new design philosophy, and you will want to support a wide range of display sizes, orientations and modes. But fret not, the tool chain is even more efficient than before, designing scalable UIs with Metro is relatively painless and you can always consider HTML5 if you're worried about the extra expenses. If you're not that interested in Metro, you can run your legacy stuff in the Desktop mode, but why would you? Metro is the future for Windows.
• If you want to develop for tablets, you will have to be aware of the differences between ARM and x86 hardware. ARM is very lucrative for its better battery life, but the remote management options are far more restricted. Even if this didn't sound like a big deal to you, it might be one for your IT department if you happen to be developing software for enterprise use. You have been warned.
• Plain old web stuff might get complicated because of the two different Internet Explorer versions. That's right, there's one for the new Metro start screen and one for the legacy Desktop mode, and they're different. The biggest difference is that the Metro version does not have any plugin support (i.e. flash is probably out, for one). Switching between the two modes is quite easy from within Internet Explorer, fortunately.

All things considered, we think it's fair to say that Windows 8 is a big deal, and it will be increasingly so in the near future. We're really excited about it, and will continue our investigation and post our findings here. Stay tuned!

Permalink | Leave a comment  »

Last week we took Pingdom into use at Futurice. Traditionally monitoring and uptime information is secret, but we didn't find any reason to continue with this tradition. If we are doing a good job with keeping our services up, we can be proud of it, and if not, we need to improve.

Our goal is to have only green markers in the front page - meaning 99.9% uptime with every service - but we are still pretty far from it. However, things are improving, and after a few months we'll have better historical data.

Some tests are more complex than just ping, which explains longer response times (>200ms). For example, www.futurice.com and blog.futurice.com actually load the HTML page and check that no error messages are present. At the time of writing, Berlin router shows red. It's not actually down, they just use a temporary internet connection after relocation to new premises.

Pingdom only monitors some services and network connectivity. Internally, we use Zabbix for monitoring server performance and availability. All information in Zabbix is available to every employee. It's not perfect, but it was the best alternative that filled our requirements.

One of our key principles at Futurice is openness, and we try to improve it by increasing transparency one small step at a time. With public status information, relevant information is shared to users without the need to contact the IT team. Unfortunately, Zabbix will be staying in the current "employee only" status, as it contains a great deal of confidential client information.

Permalink | Leave a comment  »

With the Consumer Preview launch of Windows 8, Microsoft has clearly indicated its chosen path of Metro. Ironically, the end of windowed applications appears to be nigh. While it is still possible to make traditional applications as well, we are witnessing a rush of these desktop apps that behave closer to those found in the mobile world. Metro apps, for instance, open in full screen, have negligible system privileges, and can only be installed from the Store.

As usual, there is a variety of technologies to choose from when creating native applications for Windows 8. When developing Metro apps specifically, there is a newcomer amongst the more traditional technologies: HTML5. It is not a mere half baked attempt to make the platform sound trendy, either. Microsoft is making a serious effort while hopping onto the bandwagon of the cool kids.

How they have made it happen in practice is by exposing a set of Windows Runtime system APIs to JavaScript and throwing in a couple of platform specific features. The apps themselves run in the Internet Explorer 10 engine, which supports most of the things you would ever need - and then some. Don’t hold your breath for WebGL, though.

The experience for a seasoned web developer is quite good, especially if you are already using a Windows machine. If not, you may encounter some issues, such as being effectively forced to use Visual Studio to build and run your app. It is, however, quite a reasonable requirement since you would need a Windows 8 target machine in any case to try out your code.

The main problem with the setup is unit testing - or rather, the lack of it. There is currently no proposed solution for running your tests against the real platform. You will have to rely on mocking the Windows Runtime APIs and hoping they work as you expect. This is unfortunate, but reality for now.

There are a number of other surprises, such as custom CSS media queries and the absence of the “alert” function, but overall no dramatic ones. It is perhaps as close to HTML5 as you can get while taking platform needs into consideration; even the operating system settings flyout is a div element.

The future of the Metro platform looks bright. The excellent UI design aside, Microsoft has taken a steep turn away from enforcing their proprietary technologies for developing anything at all. Hopefully this will serve as an example for the whole industry.

In short: If you know HTML5, building native Windows 8 apps should not require a lot of effort.

Permalink | Leave a comment  »

This weekend Futurice had the privilege of hosting the Helsinki edition of this spring’s Global Service Jam. In this 48–hour event, people interested in concepting and service design got together, formed teams, and created new service concepts that can “change the world”.

Once again, the Jam was very intense, but also lots of fun, and some pretty amazing work came out. People met others with similar interests, made friends, learned a lot from each other, learned even more by doing and trying things out, and in the end showed theconcepts they had put together to everyone, and made them available to the world.

Here’s a summary of what happened:

We started the event on Friday with getting to know each other and looking at what was going to happen over the weekend. Then, we listened to a most inspiring speech by our inspirational speaker Anton Schubert (ex-Ideo, now 358),who started from the wiki-definition of “community spirit” to outline the relevance of events like the Service Jam and the huge impact they can have on the world.

Then the theme was announced (“Hidden Treasures”), and after the expected moments of shock and confusion, the rest of the evening was dedicated to making sense of the theme together, and forming teams based on the common interests of the participants.

Saturday was the ‘research day’. Using early prototypes, or just interviewing techniques, all the teams had to go to the streets and gather insights on their existing ideas. The research was successful: after carrying it out, many initial assumptions were proven wrong, some crises came about, and finally new and improved solutions were found. More advanced storyboards, UI mockups and other service evidences began to emerge.

Sunday was the “do-it-all frenzy day”: some were doing video prototypes, some presentations, some logos and costumes, some final storyboards. It was probably the most fun day, because everyone needed to upload the final deliverables to the website, and felt on their own skin what the organizers had been preaching from the beginning: “Doing, not talking”, “Doing, not talking!” and “Keep it fun”. Finally, on Sunday afternoon, the teams presented their results to each other, and we ended the day with some looking back on the weekend, feedback for the organizers, cake and sauna.

And, well, here are the teams’ results:

http://planet.globalservicejam.org/gsj12/projects?field_projectlocation_nid=1145

And here are some photos and videos from the event:

https://picasaweb.google.com/116418736973434902417/HelsinkiServiceJam2012

So, not more can be said other than hats off to the participants for their amazing effort, and thanks to everyone for yet another amazing Jam!

And of course, thanks to Leyla from 358 for our cool logo this year, and thanks to the rest of the organizing team: Riitta from Hub, Katja from RAY, Reima from Palmu, and Mike from HammerKit! It’s such a pleasure to work with you guys!

Why

So why have events like this one gotten so much success lately? Why would anyone sacrifice a whole weekend, to… well, basically work, and not just work, but work at a crazy pace, with the tightest deadline you could possibly imagine? Why did the Global Service Jam get 2061 registered attendees, from 85 cities in almost 40 countries worldwide, in just its second edition? Well, there could be a number of reasons, but I’d like to discuss two of them.

The first reason could be the drive to learn by doing. I strongly believe that our education systems are not designed towards preparing people for working life, and there’s an acute need for more practical, hands–on experience.

And even though the Finnish and other Nordic systems are way closer to the real world than many others, many students are still thirsty for more real projects, for more chances to practice their skills and get connected with the business world.

It’s not just students who want to learn, of course. We had many employed professionals at the Jam, and that to me highlighted the second reason for attending: the possibility to fail. As one participant put it: “here it’s cheap to make mistakes”. Many times, in our work projects we can’t afford to fail: we know what we need to deliver, and we just have to do it. We have to meet expectations, and to do that we’ll take the routes we already know, and know well. Any failure in our projects seems to make us less of a professional because we should know our stuff, right? Well, it doesn’t work quite like that, at least for a designer. For one, we need our prototypes to fail as much as possible, because that’s the only way we can make the final outcome better.

But there’s more to it than that: it’s about having this completely fail-safe (and fun) environment, the space to explore something completely new, to get inspired, to learn something you didn’t know you needed to learn, which you can then use to bring value to your daily work. These kinds of projects are extremely valuable to us designers, and, as it seems, to other professionals as well. 

Permalink | Leave a comment  »

Woo, Futurice was just selected as the best workplace in Finland! It feels good to be recognized also by an outside party that we are going to the right direction.

Our passion is to make our workplace and all the workplaces in Finland better. Therefore we want to share you how we do it - and we would love to learn of your ways of doing it as well. Please contact us and let's set up a meeting to talk more about how to make the world a better place to work: Hanno Nevanlinna (hanno.nevanlinna@futurice.com) or Lenita Lempainen (lenita.lempainen@futurice.com).

Below you can find all our people's open comments (uncut) from the great place to work survey. Hopefully you can catch something from there for your organization!

And the press release can be found from here.

"Ainutlaatuiset edut ja halukkuus tarttua epätavallisiinkin ajatuksiin, esim. Viikko Berliinissä"
"Bonusjärjestelmän avoimuus ja reiluus, toki enemmänkin saisi tulla aina :)"
"Uusi mentorointimalli vaikuttaa hyvältä mutta aika näyttää. Äärimmäisen positiivista on HR:n halu ajatella asioita perinteisen laatikon ulkopuolelta tässäkin kohtaa"
"Avoin kulttuuri ja aito fiilis siitä ettei tarvitse pyrkiä directoriksi voidakseen vaikuttaa asioihin yrityksessä."
"hyvin vahva keskinäinen luottamus"
"avoimuus ja johdon toiminnan huikea läpinäkyvyys"
"pitkäjännitteinen, sitoutunut johto"
"ihmiset"
"Johdon kommunikointi/tiedotus on avointa ja mutkatonta"
"Asiakkaan tiloissa työskentelevistä pidetään erittäin hyvin huolta"
"Meillä on paljon kaikkenlaista pientä kivaa piristämässä työpäiviä/-viikkoja"
"monipuoliset edut: lounas- ja liikuntasetelit, alennukset badgea näyttämällä (mm. kuntosalialennus), mahdollisuus varata yrityksen saunatilat omaan käyttöön vapaa-ajalla, joustavat työajat, uusi sisäpuutarha/metsä (jossa voi pitää pieniä neuvotteluja/rentoutua), sauna lämmin aamuisin (vuorot miehille ja naisille erikseen), kampaaja käy säännöllisesti toimistolla, samoin hieroja, viikottainen aamiainen, kuukausittainen pizzapäivä, monipuolinen biletarjonta (futubileet, pikkujoulut, kesäpäivät, family friday jne), torkku/venyttelyhuone"
"mahdollisuus vaikuttaa: kaikesta kerätään palautetta, ja sen pohjalta todella tapahtuu muutoksia"
"hyvä ilmapiiri"
"Työyhteisössä aito välittämisen tunne, niin kanssatyöntekijöiltä, kuin johdoltakin"
"Hyvä, rennonletkeä meininki. Porukka viihtyy myös vapaa-aikanaankin, ja keskusteluja voidaan jatkaa vaikka pubirundilla"
"Mahdollisuus vaikuttaa työtehtäviinsä. Johto pyrkii osaltaan järjestämään (toki mahdollisuuksien mukaan) työntekijää motivoivia ja mielekkäitä projekteja / tekemistä"
"Ammatillisen kehittymisen mahdollisuudet monipuoliset, fiksusti rakennettu urapolkumalli. Palkkaus tasa-arvoinen (ja uramallia seuraileva), eikä suosi pelkästään 'taitavia palkkaneuvottelijoita'"
"Aktiivinen ja hyvin toimiva virkistystoiminta, joka järjestää paljon erilaisia mielekkäitä ja hauskoja tapahtumia"
"Monipuoliset työsuhde-edut, toimiva & kannustava bonusjärjestelmä"
"Poikkeuksellinen joustavuus työajoiss ja muissa järjestelyissä ja muu joustavuus"
"Aito avoimmuus läpi organisaation."
"Arkipäivän mukavuudet: Premium-tason kahvit ja teet ym., lämmin sauna aamuisin, aamiaiset, mahdollisuus ottaa välipalaa, mahdollisuus hierontaan ja kampaajaan toimistolla ym."
"Tunne aiitä, että on etuoikeutettu työskennellessään erityisessä työpaikassa."
"Firman halu muuttaa alaa ja esimerkillään työnantajakulttuuria myös muissa yrityksissä."
"Luotetaan ihmisiin ei ole pelkkä sanonta, vaan se on myös monella tavalla pistetty konkreettisesti käytäntöön. Firman johto on todella sisäistänyt sen, että paras työtulos (ja siten yrityksen tulos) saavutetaan sillä, että varmistetaan, että työskentely itsessään on niin mukavaa kun voi vain olla."
"Loma-aikoja saa järjesteltyä melko vapaasti."
"Paljon vapautta ja vastuuta."
"1) Minulla on vielä opiskelut kesken, mutta missään vaiheessa en ole kokenut, että työnteko opiskelun ohessa (eli opiskelu työnteon ohessa) olisi ollut este työnantajalleni. Tunnen saavani kannustusta valmistumiseen; kun olen tarvinnut keskittymistäni kokopäiväiseen opiskeluun, on viikoista muutamiin kuukausiin mittainen palkaton opintovapaa järjestynyt ilman työsuhteen katkaisemista. Lisäksi valmistumiseen kannustetaan järjestämällä dippaleiri eli parin kuukauden palkallinen jakso, jossa lopputyöntekijät vapautetaan muista työtehtävistä ja tuodaan yhteen tekemään loppututkintonsa kirjallinen osa valmiiksi vertaistuen voimin."
"2) Liikkumiseen ja urheiluharrastuksiin kannustetaan. Erilaisiin urheilutapahtumiin kannustetaan osallistumaan korvaamalla niistä aiheutuneet kulut. Kesän mittaan järjestimme jälleen ns. Futuolympialaiset, joissa vuorotellen milloin mistäkin lajista kiinnostuneet futulaiset veivät muut halukkaat työpäivän jälkeen tutustumaan eri urheilulajeihin tai liikuntamuotoihin. Firma osallistui tarjoamalla osallistujille eväät mukaan ja palkitsemalla aktiivisimmin mukana olleet kesän päätteeksi. Samoin esimerkiksi työmatkapyöräilyä tuetaan, mitä varten toimiston sauna on lämmin joka aamu."
"3) Futu-porukka on muutenkin aktiivista järjestämään erilaisia tapahtumia – oma-aloitteisesti järjestettyä vapaa-ajantoimintaa tapahtuu nykyään jos ei ihan viikoittain niin useammin kuin kerran kuukaudessa. Ne voivat olla pelailutilaisuuksia, kokkailua, oluiden maistelua tai esitelmä- tai keskustelutilaisuuksia aiheista työn läheltä tai kauempaa. Ilmoilla on hiljattain ollut myös keskustelua Futu-bändin elvyttämisestä."
"4) Vuosia jatkunut perinne jatkuu yhä, eli kerran viikossa, joka keskiviikkoaamu, työpäivä alkaa klo 9.00–9.30 järjestettävällä Futu-aamiaisella, jossa keskustelunaihe on vapaa ja tunnelma rento. Lisäksi kerran kuussa pidetään FutuFriday eli teemaperjantai, jona firma tarjoaa lounaspizzat, nähdään tai pidetään muutama workshop ja presentaatio (aihe pitäjänsä parhaaksi näkemä), vaihdetaan videon välityksellä kuulumiset Helsingin, Tampeen ja Berliinin toimistojen kesken, ja haastatellaan toimitusjohtajaa avoimin kysymyksin Ask the CEO Half-an-hour-sessiossa. Kaikkina muinakin perjantaina toimiston jääkaappi muuten tarjoaa perjantaioluet työpäivän päätteeksi. :)"
"5) Futurice on tähän päivään saakka karsinut tehokkaasti työnteon tieltä kaikkea sitä byrokratiaa ja jähmeyttä, mihin muilla tuntemillani työnantajilla usein kuluu aikaa. Esimerkiksi laskuja ei tarvitse hyväksyttää esimiehellä vaan jokainen firman luottokorttia käyttävä tekee itse arvionsa, onko meno tarpeellinen vai ei. Muutenkin Futuricen organisaatiohierarkia on erittäin matala (3 tasoa!) ja esimiesten kanssa on helppo olla tekemisissä. Ylläpidosta vastaava IT-tiimimme on erittäin vastaanottavainen ja altis korjaamaan sekä juuri sillä hetkellä haittaavan henkilökohtaisen ongelman että sen taustalla olevan, jonka pian kohtaisi joku muukin futulainen. Arvostan myös sitä tosiasiaa, että saan käyttää ja itse päivittää parhaaksi näkemääni omenanmakuista työkonettani enkä joudu tyytymään minkään ulkoisen palveluntarjoajan asettamiin päivityssykleihin ja laitteisiin."
"Tämä on ehdottomasti paikka, jossa vallitsee hyvä ilmapiiri varsinaiseen työntekoon eli asiakkaiden ongelmien ratkaisemiseen!"
"Aito kiinnostus siihen, että työntekijöillä olisi niin henkisesti kuin fyysisestikin hyvä ynpäristö tehdä työtään. Työntekijöiden näkemyksiä kuunnellaan ja pyritään mahdollisuuksien mukaan tekemään työntekijöiden toivomia hankintoja, esim. uudet työtuolit. Tässä työpaikassa on poikkeuksellisen hyvä ilmapiiri, huumori kukkii ja jokainen saa olla oma itsensä. Rekrytoidaan henkilöitä, jotka sopivat joukkoon ja tässäkin kuunnellaan työntekijöiden näkemyksiä siitä, onko haastateltu henkilö tiimiin sopiva vai ei."
"Aktiivinen pyrkimys eliminoimaan turhat hallinnolliset prosessit ja järkeistämään niitä välttämättömiä, jotka ovat kömpelöitä / ikäviä."
"Alalle poikkeuksellisen korkea luottamus työntekijään."
"Arvostan erityisesti yleistä halua viedä asioita eteenpäin ja tehdä asiat hyvin - positiivisella asenteella. Voin luottaa siihen, että kollegat antavat täyden panoksensa työtehtäviin."
"Meillä on myös hemputin mukava fudisjoukkue."
"Asiat toimivat. Ihmiset ovat osaavia, fiksuja ja mukavia. On ollut mahdollista tehdä myös kiinnostavia asioita, jotka eivät liity suoraan työtehtävään ja on ollut mahdollista vaikuttaa työtehtäviin."
"Asioiden tila on mahdollista helppo johdon tukemana, jos oikeasti tarvetta. Hyvä mahdollisuus tehdä juuri niitä asioita, joita itse haluaa. Poikkeuksellisen hyvät työsuhde-edut työntekijöille."
"Avoimmuus ja työntekijöiden motivointi: työntekijöitä ohjataan aktiivisesti kehittämään itseään ja organisaatiota."
"Avoimuus, kaikesta firman toiminnasta kerrotaan. Kynnys kysyä johdolta on myös matala. Sellainen olo että voisi mennä kysymään mitä vaan. (Ja myös saa vastauksen. Jos ei heti niin pian kuitenkin.)"
"Best balance work/private life ever :"
"    - COMPLETELY free schedule"
"    - Opportunity to have a permanent part-time contract"
"    - Opportunity to take a leave whenever you want"
"Best parties, friends are invited as well as customers and employees from other companies in the same business, there is food and drinks for everyone."
"Very highly skilled but still very humble people."
"Pool table, sauna, video games, free fruits at will, free cookies at will, free juices at will, ..."
"Breakfast buffet every Wednesday"
"Special event every first Friday of the month : company offers lunch, pizza, salads, ... we have talks, workshops, coding sessions, ...."
"Once a year, our CEO invites everybody individually to have a talk with him, give feedback, suggestions, and he explains the strategy to each and every one ..."
"And so much more ........"
"Erinomainen panostus HR-työhön! Loistavat mahdollisuudet keskustella ylemmän johdon kanssa! Uskomaton läpinäkyvyys johdon toimintaan! Erityislaatuinen rekrytointiprosessi, jossa varmistetaan uusien työntekijöiden sopivuus! Tampereen tiimi on täysin ainutlaatuinen upean tiimihengen ja osaamisen osalta!"
"Erittäin suuret mahdollisuudet vaikuttaa työhön ja projekteihin, jos haluaa."
"Erityisen hyvän työpaikan työpaikastani tekevät yrityksen arvot, mielekkäät työtehtävät, mukavat ja ammattitaitoiset työntekijät sekä laaja tarjonta vapaa-ajantoimintaa. Lisäksi paljon muita kivoja etuja, kuten yhteinen aamupala kerran viikossa, palkkapäivänä pizzaa, liikuntasetelit, paljon erilaisia tapahtumia jne."
"Futurice is really unique IT company. Top managers and company owners are the same guys who created company 11 years ago and they REALLY trying to build company that balances three factors: People - Customers - Company finances. Every single day people are discussing how to make company work better."
"Futuricella on ainutlaatuinen, avoin ja mutkaton kulttuuri, josta kerron mielelläni myös ystävilleni ja tutuilleni."
"Futuricella on mahtava tekemisen meininki."
"Futuricella on helppo kehittää omaa uraa siihen suuntaan, mihin itse haluaa. Yritys tarjoaa siihen erinomaiset puitteet. Itse olen päässyt jo aivan juniorina tekemään tiiviisti töitä johtoryhmän ja hallituksen kanssa - ja olen kokenut, että minut on otettu mukaan tasa-arvoisena työkaverina eikä junnuna."
"Firman yhteiset aamiaiset, FutuFridayt + payday-pizzat, erilaiset yhteiset juhlat ja muut tapahtumat luovat mainiot puitteet yhteisöllisyyden ja hyvän tekemisen meiningin kasvattamiseen."
"Futuricella jokaiseen luotetaan ja luottamus myös osoitetaan oikeilla teoilla ja toimintatavoilla: yrityksen kaikki luvut ovat julkisia; jokaisella työntekijällä on oikeus tehdä päätökset, jos heillä on paras tieto päätöksen kannalta oleellisista asioista - ts. kaikki ylimääräinen byrokratia on poistettu; jokainen työntekijä saa myös oman firman luottokortin..."
"Futuricella välitetään ihmisistä aidosti. Se näkyy erilaisina järjestettyinä aktiviteetteina ja mahdollisuuksina (esim. aamiaiset, sauna- ja keittiötilat), erilaisina etuina (esim. joustavat lomailu- ja perhevapaamahdollisuudet ja erinomaiset vakuutukset), mutta myös päivittäisinä tekoina (esim. Futuricella on vahva positiivisen palautteenantokulttuuri, jonka toteuttamisessa toimitusjohtajamme on varmasti yksi malliesimerkkejä)."
"Henkilökunnan samanhenkisyys. Ihmiset pitävät työnteosta ja ovat oikeasti kiinnostuneita näistä jutuista myös työajan ulkopuolella. Toisin sanoen mä oon vaan töissä täällä -asennetta ei tule vastaan."
"Huumori, kulttuuri. Tietynlainen design sensibility kaikessa tekemisessä. Kaikki ymmärtävät, että pyrimme tekemään jotain todella hyvää. Lisäksi asiat tehdään meille työntekijöille mahdollisimman helpoiksi, voimme keskittyä olennaiseen."
"Hyvin menee jee jee"
"Ihmiset, innostuneisuus, kunnianhimo. Halu olla paras mutta kuitenkin omalla tavallamme jalat maassa. Monet projektit ovat sellaisia, joissa on suorastaan kunnia saada olla mukana."
"Työajan ulkopuolella kulutamme huomattavia määriä aikaa työkavereiden kanssa ihan vapaaehtoisesti. Usein puhutaan firman asioista, ja epäkohdat nähdään, epätoivoon vaipumisen sijaan, haasteina ja  paikkoina kehittyä. Monet firman toimintaa kehittävät asiat ovat lähteneet juuri tällaisista spontaaneista illanvietoista."
"Kaikessa tekemisessä huokuu avoimuus. Ei pelkästään sisäisessä kommunikaatiossa ja päätöksenteossa, mutta näin halutaan toimia myös ulospäin asiakkaiden suuntaan mikä on erityisen hienoa. Tämä tuntuu käsittämättömältä normaaleihin isoihin firmoihin ja kankeisiin tapoihin tottuneelle."
"Kaikilla on mahdollisuus vaikuttaa yhdenvertaisesti yhtiön tulevaisuuden suunnitelmiin ja operatiiviseeen tekemiseen ja tämä myös toimii mutkattomasti yhtiössä."
"Kaikki työntekijät ovat hemmetin hyviä tyyppejä. Tuntee olevansa erittäin fiksussa porukassa ja motivaatio pyrkiä itsekin hyviin suorituksiin nousee."
"Koen että Futuricen johto aidosti uskoo että pitämällä työntekijät tyytyväisinä, saadaan myös aikaan paras tulos. Meillä lähtökohtaisesti luotetaan siihen että jokainen tekee parhaansa, jolloin ei ole tarvetta valvoa ja johtaa niin paljon. Tämä antaa tarpeeksi liikkumavapautta, jotta työntekijä (näin uskoisin) tuntee saavansa olla mukana päättämässä asioista, ja voivansa omalta osaltaan olla mukana kehittämässä Futuricea vielä parempaan suuntaan."
"Kun tulin uutena työntekijänä taloon, joka ikinen ihminen toimitusjohtajaa myöten tarjoutuivat auttamaan minua ja saivat oloni tuntumaan todella kotoisaksi. Joka päiväisessä projektityössä Futulaiset auttavat aina toisiaan ja asiakkaita eikä kenenkään tarvitse huolehtia yksinjäämisestä. Yleisilmapiiri on aina ilmoinen ja kenen kanssa vaan voi jutella. Olen oikeasti ylpeä firmastani!"
"Lähestulkoon täydellinen läpinäkyvyys päätöksenteossa."
"Last Friday I launched a initiative to have the long term corporate goals decided upon by all employees together is an election. I could do this not because I was in upper management but because I had an idea, passion and the management just said 'great, go for it!' and this saturday I was able to use the companies' sauna and kitchen space for a private party without any rent or anything. This is a standard option open to all employees. Yes this is an unusual place to work!"
"Mageet värkit, smoothiet jääkaapissa, TaxiButton!"
"Mahtava yhteishenki ja toisista välittäminen! Viikottaiset fiiliskierrokset, joissa käsitellään myös työn ulkopuoliset asiat ja reagoidaan heti jos on tarvetta."
"Tekemisen meininki ja mielenkiintoisten projektien etsiminen jokaiselle. Pyritään aina löytämään projekti joka vastaa henkilökohtaisiin kehittymistavoitteisiin ja kiinostuksiin."
"Matala hierarkia: johtoa ei mielletä esimiehiksi, vaan ensisijaisesti työkavereiksi - toimitusjohtajaa myöten."
"Mahtava yhteishenki. Kaikki asiat yritetään tehdä ajatuksella. Kommunikointia rohkaistaan aktiivisesti, johto läsnä ja kuka tahansa voi (ja uskaltaa) nykiä hihasta. TJ pitää kaikkien kanssa pienen juttutuokion. Kaikessa pyritään toimimaan avoimesti ja läpinäkyvästi."
"Mahtavaa tulla työpaikalle, jossa ihmiset oikeasti antavat toisilleen positiivista energiaa. Vaikka olisi itsellään huono aamu, niin töihin on kiva tulla kun tietää että siellä odottaa iloinen ja positiivinen meininki"
"Management really gets it: software is about people instead of processes and tools, and they focus on keeping the people happy."
"Great transparency, flat hierarchy. I consider my management as part of my team instead of ivory tower superiors."
"I consider my coworkers my friends and gladly spend my free time with them. In fact, I look forward to Fridays to have a couple of beers with them."
"The company does not only focus on hiring talent, but talent that fits the company culture."
"Me oikeasti yritämme muuttaa toimialaamme ja parantaa maailmaa. Se on aika raju tavoite."
"Meillä ei ole hierarkiaa, meillä ei ole byrokratiaa, meillä on vapautta ja vastuuta!"
"Meillä on todennäköisesti alan paras IT-tiimi. Tiimi auttaa muita työntekijöitä välittömästi ja pyrkii ratkaisemaan ongelmat mahdollisimman hyvin. Minulla ei ole yhtään huonoa tai edes keskinkertaista kokemusta IT-tiimin kanssa. Palvelu on aina ystävällistä, erinomaista ja muut huomioonottavaa."
"Minustä tärkeää on suhtautumistapa työntekijöihin ja työympäristöön - se on yksi tärkeimmistä painopisteistä yrityksen kehityksessä. Tällä aluella olemme jo erittäin hyviä, mutta siihen ei tyydytä, vaan jatkuvasti haetaan parannusta."
"Erityisesti näen hyvänä sen, että ryhdytään konkreettisiin toimiin jo ihan toimivan työympäristön parantamiseksi. Esim. uusi toimintatapa, jossa työntekijöiden uratavoitteet ovat julkisia ja kuukausittain keräännytään tiimin kesken käymään läpi, mitä kukin on tehnyt niiden eteen ja erityisesti mitä työkaverit voivat tehdä auttaakseen muita kehittymään haluamallan tavalla."
"Nutritional company breakfast with colleagues on Wednesday mornings."
"Everything works: great support and IT infra."
"Company past-time events are great and kick ass."
"Olin juuri kahden kuukauden diplomityöleirillä, jonka aikana sai siis keskittyä kirjoittamaan diplomityötä ja maksettiin myös palkkaa. En ole kuullut, että missään muualla olisi tällaista. Työtehtäväni vastaavat sitä mitä tekisin vapaa-ajallanikin (grafiikkaa ja koodausta), joten ei tämä hirveästi työltä tunnu."
"Omassa asemassani olen saanut etsiä oikean porukan ympärilleni ja rakentaa toimintaa hyvin vapain käsin, sopivasti ylimmältä johdolta coachausta ja suunnanvahvistusta saaden. On hyvin vaikea kuvitella työpaikkana mitään mielekkäämpää positiota ja työympäristöä kuin meillä on."
"Onnistumisista, pienistäkin, palkitaan Jolt-colalla! Pieni mutta hieno ele hyvin tehdystä työstä!"
"Firmassa on erityisen rento ja rehellinen asenne. Samalla kuitenkin työhön suhtaudutaan vakavasti ja ammattimaisesti. Täällä ei tarvitse yrittää  tai esittää mitään. Riittää, että tekee työnsä hyvin."
"opiskelun ja työn yhdistäminen onnistuu erinomaisesti, FutuFriday on loistava, tiimin action-päivät oikeasti hauskoja, täällä on vapaus valita parhaat työkalut ja olen ylpeä ollessani töissä Futuricellä"
"Organisaatio ei ole kovin hierarkinen, ja jokainen työntekijä voi halutessaan ajaa mielestään hyviä sisäisiä hankkeita eteenpäin. Ylemmältä johdolta ei ole välttämättä tarvetta hakea hyväksyntää, ellei hankkeeseen kulu erityisen paljoa resursseja."
"Pääse vaikuttamaan omiin tehtäviinsä, on riittävästi erilaisia tehtäviä eri makuun, johto kuuntelee kun sille puhuu ja myös kertoo uutisia kun niitä on, IT-palvelut toimii hyvin."
"Parhaat ihmiset! :)"
"Pyrkimys autonomiaan mahdollisimman monissa asioissa, luottamus työntekijöihin on todella suuri."
"Kaikki työntekijät tietävät jatkuvasti, miten firmalla menee taloudellisesti."
"Firman strategiaa luodaan yhdessä, ei pelkästään johtajien tornissa niin kuin useissa muissa työpaikoissa."
"Pystyn kehittämään ammatillista osaamistani työn kautta ja vaikuttamaan sen suntaan. Aamupalat, tiimilounaat ja muut yhteiset tapahtumat ovat luoneet hyvin hengen."
"Pystyn kieltäytymään työtehtävistä, joita en eettisistä syistä pidä mielekkäinä"
"Se että kaikkia työntekijöitä kuunnellaan ja kaikki ovat tosi mukavia tyyppejä!"
"Siitä huolimatta, että organisaatio on kohtuullisen iso, työntekijät voivat halutessaan tehdä työtehtäviä parhaaksi katsomallaan tavalla. Samaan aikaan toiminnalle annetaan kuitenkin tarpeelliset raamit, joiden puitteissa toimia."
"Sosiaalisuuden kultivoiminen: palkkapäiväpizzat, yhteisaamiaiset, yhteinen kahvitauko jne."
"Success and extra efforts are being honored and well communicated. One's well being is important to people around, problems can be openly discussed and solved together. I feel this company is doing really well with their employees and customers, communication is at the heart of everything, making it a great basis for resolving conflicts and tackling problems early. Colleagues are helpful and the overall atmosphere is extremely pleasant."
"Systemaattinen työntekijöiden hyvinvoinnin ja viihtyvyyden huomioonotto - strategiatasolle asti. Kannustetaan miettimään työntekijöiden näkökulmaa kaikessa päätöksenteossa. Motivoituneet ihmiset HR-porukassa katsomassa, että asiat hoituvat, niin kuin pitää."
"Täällä ei koskaan haeta syyllisiä eikä rähjätä, mistä syystä epäonnistumista ei tarvitse pelätä. Tällöin on helpompi kokeilla uusia alueita/tehtäviä, joissa ei ole aiemmin toiminut. Lisäksi organisaatio on hyvin matala ja itseorganisoituva - tästä syystä kysymykset koskien uralla etenemistä ja johdon onnistumista työtehtävien koordinoinnissa tuntuivat hassuilta. Muita etuja: keskiviikkoaamiainen, palkkapäivän pizza, perhejuhlat lapsille, työntekijöiden, tiimien tai projektien virkistystilaisuudet, mahdollisuus käyttää saunaa, keittiötä, biljardipöytää ja pelikonsoleita ilmaiseksi yksityisiin tilaisuuksiin työajan ulkopuolella, urheilutoiminta."
"Täyttäessäni noita vastauksia pysähdyin miettimään, kun koko ajan tuli vain täysin samaa mieltä, että onko todella näin. Kävin vielä uudelleen kaikki sen sivun kohdat läpi, ja kyllä: täällä nähdään paljon vaivaa juuri noiden asioiden eteen ja tulokset ovat hyvät. Maailma olisi parempi paikka, jos tämän kaltaisia työpaikkoja olisi enemmän :)"
"The best thing about working in Futurice is being part of a great culture of openness and transparency. Everyone can talk openly with everyone and almost all company information is shared with everyone. Also, special care is taken that everyone feels great at work - and feedback is taken seriously into account and actions are taken when something needs to be improved."
"Toimiston vahva identiteetti ja me-henki. Seinille itsekseen ilmaantuvat hupikuvat. Mahdollisuus bändin kanssa treenaamiseen toimiston tiloissa. Mahdollisuus kysyä ja pyytää apua keneltä tahansa ja saada apua; ei keskinäistä kilpailua vaan yhdessä tekemistä ja toistensa auttamista. Mahdollisuus vaikuttaa omaan työympäristöön ja tulla kuulluksi. Jokaisen henkilökohtaiset rupattelut toimitusjohtajan kanssa. Aktiivinen puuttuminen ongelmakohtiin, jos niitä ilmenee. Aamupala viikottain ja pitsaa palkkapäivänä. Joustavuus työajoissa ja -oloissa."
"Transparency from top to bottom, no bureaucracy."
"Tunnen, että olen täällä pitämässä hauskaa kavereiden kanssa, en tekemässä työtä. Silti, tai juuri siksi, työ sujuu paremmin kuin missään aiemmassa työpaikassani."
"Työkaverit ovat poikkeuksellisen hyviä tyyppejä. Päätöksenteko on kaikilla organisaation tasoilla erittäin läpinäkyvää"
"Työkaverit ovat todella päteviä työssään. Koen, että minua ja osaamistani kunnioitetaan täällä. Haluamme yhdessä olla ylpeitä siitä mitä saamme aikaan täällä."

Permalink | Leave a comment  »

A couple of weeks ago, together with Restaurant Day volunteers, we organized a weekend-long camp at our Helsinki office. Our goal was to create mobile applications for the Restaurant Day concept.

A quick introduction to Restaurant Day (or Ravintolapäivä as it's known in Finland): it's a day during which people are encouraged to set up a pop-up restaurant. It was organized for the first time last May, and has seen spectacular growth, both in popularity and geographically. The whole event is organized by volunteers, and as such there is no commercial pressure involved. Everything is done for the love of food and the rush of organizing something great.

Close to 20 people signed up as volunteers to come help design and build the mobile applications. In addition to IT professionals – coders and designers – we also had excited people from completely different fields participating. They were interested in how mobile applications are built and wanted to help out in some way.

Based on the areas of expertise of the volunteers, we set ourselves a challenging goal. We would build applications for the iOS, Android, Windows Phone 7 and Symbian^3 mobile platforms. Making the goal even more challenging was our hard deadline: the next Restaurant Day was three weeks away, on the 4th of February. With the different application store review processes, this meant that we would have to submit our applications by the end of the following week.

On Friday, we focused on design. After introductions, we had an ideation phase, followed by MoSCoW prioritisation by Jyrki, the Restaurant Day CTO and our official product owner. The group then split up into platform teams (backend, iOS, Android, WP7, Symbian) to start setting everything up while the UX team drew up the first version of the general wireframes. These were presented, after which platform-specific UI tweaks were taken into consideration. The back-end team also drafted up some API specs. We finished the evening with a sauna and a trip to Kaunis Kampela, the local bar.

On Saturday, coding began. The UX team started making graphics and tweaking the wireframes. We had checkpoints during which everyone presented what they had achieved and others gave feedback. Lunch and dinner flew by, and coding stopped sometime after 01:00.

Coding continued on Sunday along with UI tweaks, checkpoints, food and drinks. At around 17:30, we had a final demo. The results:

During the following week, we did some further testing, made some minor user interface tweaks and finally submitted the applications for review. Today, the last application received its stamp of approval from Microsoft, and all of them (along with a video recap of the weekend) can now be found at the Restaurant Day site.

The mobile camp weekend was a real eye-opener. It is a perfect showcase of how much can be accomplished in an extremely short timeframe with a clear vision, the right technology, tools and skilled people operating them. I believe that one crucial factor – in addition to having great participants – was having a product owner who had the final say in what would be done. Lots of great ideas were thrown around, but with such a tight schedule, we had to throw excellent ideas out of the window. Let's hope to see them in version 2.0!

I want to thank all the participants for making the weekend a success, and hope that the new mobile dimension will make Restaurant Day even more enjoyable for all participants. Enjoy your culinary experiences this upcoming Saturday!

Permalink | Leave a comment  »

How do you achieve high quality, satisfied users, happy developers, and minimal downtime when developing a live digital service? Sufficient conditions for these goals are yet to be discovered, but you'll have a hard time achieving any of them without proper environments.

Then, what is the proper set of environments for server-side software development? Here's our take on the matter.

Development
This is where you write code. The product you're building can be run here, and any changes to it can be tested with minimal delay. Integrations to external services are replaced with mockups or stubs to avoid daily work being interrupted by network issues or server downtime. In particular, any databases are local. However, highly available public services may be used as such.

Continuous Integration
Continuous Integration (CI) builds your product and runs all automated tests as soon as anything changes in the codebase. Failures are reported immediately. CI also runs end-to-end integration tests.

Testing
The Testing environment used by dedicated testers doubles as a production-like playground for developers. External integrations are by default set up to staging-level versions of other services. Developers can experiment with and try out new integrations here—this environment is also known as Integration Testing.

Demonstration
This one's optional. Depending on your approval process, the demonstration environment can be used to allow for stakeholders to review changes on their own schedule before approval for production.

Staging
This one goes by many names: staging, QA, or pre-production. If a release breaks something in production, it will break identically here. Thus the staging environment is set up exactly like production (except for necessary configuration parameters), and kept like production between releases. Mysterious production issues can be debugged here. Dedicated testers can also use this environment.

Production
The real deal. Never ever modified in any way without rehearsing in staging first. Regular clean-up is scheduled for accumulating data, such as logs and temporary files.

We've found that this set helps developers to come up with the best technical solutions and resolve issues quickly, and users will only ever notice a new release by the product's increased awesomeness.

Do you think we're missing something essential? Is there something you would leave out?

Permalink | Leave a comment  »

When you are just a couple of people starting up a company, your goals are often straightforward and well understood. But as your company grows and becomes too big to have everything work without effort, it is time to think about what brings everyone together as a group of people and what the purpose of the company is. Here I am not talking about the legal entity 'company', whose goal it is to generate profit, but about the people. Why do they get out of bed – just to get a paycheck each month? For the sake of your long term success, I hope the answer to that is not "yes". 

For those who are unsure about the validity of this claim, here are some links to check out:

http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

http://www.amazon.com/Start-Why-Leaders-Inspire-Everyone/dp/1591842808

http://hbr.org/1996/09/building-your-companys-vision/ar/1

So also began Futurice's discovery to the "why". I specifically use the word discovery because your long term identity and goals should flow from who you are. It should not be an invented why.

One of the elements in this discovery is our BHAG (big, hairy audacious goal; see wiki: http://en.wikipedia.org/wiki/Big_Hairy_Audacious_Goal). Initially, we had several closed discussions about the subject, but we couldn't shake off a nagging feeling that we were doing it wrong. So we decided to do it differently, and make use of all the bright people in our company. 

The format we ended up with was an election. From our previous discussions, we had three rough outlines of possible goals, and asked three people to represent them. The candidates will gather campaign teams that will start the discussion to improve those rough goal outlines to their finalized form. During the campaign, we will discuss and try to answer questions like "What are the merits of this particular goal?", "Why does it fit Futurice's values?", "How do we know that we have reached the goal?", "How does this goal make the world a better place?", etc. After the discussion – which, of course will include an election debate – it is time to vote and set our long term goal. 

Why did we choose an election? Two reasons. First, it involves everybody. Everyone has the chance to have their voice heard as to what we should be striving for. The second and maybe most important reason is the resulting discussion. Discussion leads to discovery, and discovery leads to better decisions. The combination of the two ensures that the outcome has been thoroughly scrutinized and has broad support.

Your long term future is too important to be decided by a couple of people sealed off from everyone else. The discussion should be out in the open, involving everybody and the outcome should be supported by more than just management. We have a company which values trust and taking responsibility. We try to recruit the best and brightest with an interest reaching far beyond their own desk. It would simply be silly not to use that huge potential to shape our future.

Currently we are forming the campaign teams and defining the candidate goals. After the New Year we start the campaigns, and voting will most likely take place in March.

Follow our efforts to discover our future by following us on twitter http://twitter.com/futurice or keep an eye on this blog for updates on the Futurice goal election.

Permalink | Leave a comment  »

Here is a quick 14 minute introduciton to mobile application development, why it is (finally) real and how to specify your projects and deploy your applications to best effect. This was an internal Futurice presentation from Helsinki, simulcast to Tampere and Berlin.

Permalink | Leave a comment  »

At Futurice, we use Django rather heavily for internal tools such as reporting, virtual machine management and integration between miscellaneous systems. Django enables very rapid development and includes a large number of modules and plugins. In addition, Django documentation is outstanding.

There are a few tools that I believe everyone using Django should be familiar with: South (database schema migrations), Sentry (error reporting) and Reversion (model version history).

South creates database migrations automatically with only a few commands. Without South, changes require running SQL ALTER statements manually or deleting database tables and recreating them (after creating a backup first, and then restoring it, of course). Taking South into use is really simple: just add "south" to the project settings (under INSTALLED_APPS) and run the initial schema migration, which just records current models. After changing models, applying changes to the database requires just two commands:

./manage.py schemamigration <app name> --auto
./manage.py migrate <app name>

This preserves all information in the database, assuming no field was truncated or deleted. So, for example, changing a field from integer to float is fine, but not necessarily the other way around.

South migrations are Python files stored inside the Django app, with names like "0012_auto__del_field_comments__chg_field_timestamp.py". That's the 12th migration that was automatically created which deletes the "comments" field and changes the "timestamp" field. South can also handle data migrations: for example, if the timestamp is stored in Unix time (seconds since 1.1.1970) in an integer field, a simple South migration can handle adding a proper DateTime field and converting the timestamps. One caveat with sqlite is that it doesn't support altering unique constraints. However, South gives a warning message when it encounters this - so it's not a hidden surprise to be detected later on.

Sentry is a generic interface for browsing exceptions thrown by Django or by any other Python application. By default, Django emails every single error report to the developer's email address. This is quite annoying with a busy web application: it might send hundreds of emails within a few minutes. Sentry handles this problem by grouping identical error messages as one. In Sentry, "identical" means an error with same traceback, not per client IP address or similar details.

Sentry is installed by adding it to INSTALLED_APPS and adding the middleware to catch exceptions. When running multiple Django applications, a centralized Sentry server is useful. In Futurice, one Sentry server provides access to nearly all Django application error reports (about 15 different applications). The Sentry UI works well, with added Ajax niceties. No system is perfect though: different versions of the Sentry server and client do not always work nicely, and, in case of problems, it fails silently.

Reversion handles version control for objects in the database. Basically, if any object is modified, Reversion saves modifications and allows reverting to old versions. Integration to other parts of applications goes through middleware (adding a single line to the project settings file) or with decorators (for saving changes only in specific methods) or by using "with" statements (for saving changes only in specific places). The easiest way to browse the version history is through the Django admin interface. Reversion even adds automatic comments to versions: for example "Changed description" when the description field was updated.

Of course, there's a long list of other useful packages and tools. Just to list a few: virtualenv, django-debug-toolbar, django-annoying and haystack.

Hopefully you found a new useful Django tool with the post that will make your development efforts easier in the future!

Permalink | Leave a comment  »

We got our brand book done! We found that it was hard to catch the idea what the book should be like because examples are poorly available, so here is ours: http://www.futurice.com/brandbook.pdf . Hopefully this is useful to others.

The book has three purposes:

• To show the origin of our brand
• To clarify Futurice’s brand essence and brand personality
• To provide brand guidelines for our communication

Here is how the brand story goes:

Three engineers walked into a bar...

It all began with a few engineering students doing what they do best: creating interesting things through clever coding. This small group of friends had a passion for using the latest technology to create smart, convenient, and exciting solutions to everyday problems.

They were devoted to their creations and felt a sense of real ownership and responsibility for what they made and what it could do. Satisfied clients spread the word about the new, resourceful, and down-to-earth player in the market.

One engineer said...

The friends were excited to realize that the approach that they offered – fresh, unpretentious, clever – was one of the main reasons that people wanted to work with them.

They figured, “Let’s get this going. Let’s make it happen. But let’s promise never to get stuck on the corporate conveyor belt.” They wanted to stay inspired – to run a flexible, thoughtful, outward-looking business, not a code factory.

To get the best results they realized they’d need to create multi-talented teams made up of all sorts of skillful and gifted people.

When the engineers left the bar...

...they took a few friends with them, including, down-to-earth artists from the school of art and design, entrepreneurial businesspeople, and energetic individuals from all sorts of fields. Futurice emerged out of its modest beginnings and into the corporate world.

New, young, gifted students – not just engineers – start at Futurice every year: we take on people who are energetic, eager to learn, and who aren’t jaded by the industry.

Our roots are in engineering, but we see our engineers as designers, sculptors of ideas, and social architects. And regardless of our backgrounds, we’re all working together to engineer a new future with our customers.

They started a journey...

And it’s getting more and more interesting.

Because for Futurice, software design is not just about solving immediate problems, it’s about positively influencing the bigger picture for our clients. We want to provide options, broaden horizons, change mindsets, and give our clients new tools and new perspectives on the way they operate.

At the ten-year mark Futurice had around 150 employees and a global client base. Our designs continue to incorporate sensitivity and human understanding, and consider all angles of the user experience.

We consider the social impact of the designs we create, and we trust that intuitive design will stimulate renewal in the tech-driven engineering world.

But they stayed in touch with their roots.

While we continue to grow, and the future’s looking fantastic, our down-to-earth attitude and entrepreneurial spirit never changes.

Our capacity to constantly evolve, adapt, and evaluate our own work practices to better serve our clients makes us an eternal start-up, no matter how big we grow.

So, how many engineers (and their friends) does it take to change an industry?

We don’t know yet, but we’re dedicated to finding out.

To read more, download our brand book at http://www.futurice.com/brandbook.pdf

What is your own story? :)

Permalink | Leave a comment  »

Ordering a taxi should be as easy as purchasing things from Amazon, right? That's what we made to our office lobby.

Pressing the button orders an SMS taxi to our office. Display shows order status and after taxi confirms the order, taxi number.

List of parts:

• Taxi post from Trafino, about 200€
• Mobile broadband USB stick (Huawei E230), for sending and receiving SMS messages, 80€
• Button from internet, 10€
• Arduino, for connecting button to computer, 20€
• Cable for connecting button to Arduino

In total about 310€ plus small desktop computer and display. Our display also shows bus timetables for nearby bus stops and weather information for our offices in Helsinki, Tampere and Berlin. Bus timetables require HSL API key. Weather information uses weatherbug API. 

We put up github repository for the code with some very short instructions. Whole system was put together just before our annual party, so it's not particularly production quality code. It's licensed with GPLv3, so feel free to use and modify it.

Permalink | Leave a comment  »

The drive to give something back to society–or to contribute–is not an isolated trend. There are countless examples out there of people contributing some of their time and resources to causes they believe in. Especially in a wealthy society like the Finnish one, and especially for people working in privileged fields like IT, it’s not uncommon to find people who just want to give something back, one way or another.

I was once more a witness of this growing trend last weekend, when a group of 20-or-so very inspiring individuals got together at Hub Helsinki and spent 48 hours coming up with new concepts on sustainability. It was the Global Sustainability Jam, and the group in Helsinki was one of the 42 groups taking part in the event all around the world.

As one of the organizers of the Helsinki event I wanted to see if there was anything Futurice, my company, could do to help us out. Some food and drinks never hurt in an event like this, and that was something easy to ask for. More importantly, though, I’m interested in finding a model in which companies can get involved in these events and do their share of contribution, and at the same time make it easier for people to contribute without compromising their work-life balance. So, some of my company time was another thing I wanted to ask for.

Knowing how careful we here at Futurice need to be with our budgets, I wasn’t expecting anything to be just handed out, so I prepared a good list of arguments of how a sponsorship might benefit our company. I made sure I put everything in terms of Futurice benefitting, and not in terms of pro bono contribution.

But to my surprise, I had jumped to conclusions way too fast. After a series of discussions about the project and our potential involvement, I was finally told: “Oh, now I understand. This is about contributing to a cause, not about marketing. Well, why didn’t you say so? Just take what you need as long as it’s reasonable”

As it turns out, contribution is a possibility with companies as well. Maybe it’s not always that visible, and maybe it’s not a value shared by everyone in a company, but it’s certainly possible!

So here is what I learned from this and wanted to share with all those “contribution enthusiasts” out there, be them in Futurice or any other company:

1. Ask and you shall receive. Don’t just assume that your company only cares about profits and whatever other business objectives. Just take initiative, and you might be surprised of the outcome.
2. There are many like you out there. Don’t think you’re the only one who wants to contribute in your company. You’ll be surprised at how many others might have similar motivations, even people in very high positions.
3. Let’s not keep this as a secret, there’s nothing to be ashamed of. I can only imagine the impact we could have if contribution was a bit more out in the open…

So, let's contribute more together and see you at the next jam!

Permalink | Leave a comment  »