Futurice Blog

Decision making in Futurice

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.

Click here to download:

Futurice_Decision_Making.pdf (413 KB)

(download)

Click here to download:

Futurice_Decision_Making.pdf (413 KB)

Posted by Eemeli Kantola 

Consider maintenance from the beginning

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.

Posted by Tuomas Paasonen 

New public status pages

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.

Posted by Olli Jarva 

Agile maintenance - Are contracts necessary?

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.

Posted by Rauli Poikela 

Lifecycle Management - Selling a concept for agile maintenance

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.

Posted by Rauli Poikela 

Re-inventing custom software maintenance

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.

Posted by Teemu Turunen 

Asking designers: to code or not to code

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!

Posted by Sebi Tauciuc 

Windows 8 - Why and How?

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!

Posted by Harri Dahlgren 

Public performance and uptime information

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.

Posted by Olli Jarva 

Metro on Windows 8 with “Native HTML5”

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.

Posted by Timo Tuominen