Futurice Blog

Customer's Role in Project Success

Summary

How can you ensure you will achieve a successful outcome quickly with good value for money? Futurice has performed Bayesian statistical analysis of project success factors using modern mobile and web technologies and our own Agile working methods.

Our recommendations for you, as a customer participating in the development project, are summarized below. These are grouped by how you can influence different aspects of the outcome.

Key Success Factors

As a customer, you are more likely to be happy with the outcome when

1. You work with the team to make them really understand your service
2. The schedule is not overly optimistic
3. New technologies were not adapted into the project

The project will go as expected when

1. There are no external partners, factors or unknowns that can change the project midstream
2. You and the team have work together to share your expectations on the outcome
3. The project has a clear focus and scope

The resulting product or service will be good when

1. You define very clear goals for the project before we start
2. You have worked with technical product or service development before
3. You work hands-on with some aspects of the project along with our team

 The project will be completed in budget when

1. The project schedule is relaxed
2. You have worked with technical product development before
3. The project does not have unknowns and external dependencies
4. The project is arranged as one larger project run continuously rather than a series of smaller projects which stop and start

Practical Steps For Getting It Right

The statistics can help us predict which projects will succeed in which areas. Additionally, we have developed own working best practice recommendations. When possible, these should be in place at the start of the project to create the preconditions for success.

1. If the product to be developed is based on an existing product, provide the complete working model to the team. Take an inventory of any areas that are missing or not yet working and carefully schedule when the associated unknowns or external factors will be cleared and ready.
2. If you are providing the user interface, have a nearly final design ready as 1 or 2 documents before work begins. Delays and changes in external designs are a common cause for delays and poor project satisfaction.
3. If you, Futurice or a 3rd party is providing a server which is not yet complete or has recently changed, have the server team create a single web page where every server function can be individually tested at any time by the server team, you and Futurice. Incomplete features should also be listed here, clearly indicating what is working at this moment and what is still to come. This high transparency for all parties about the current state of the server clarifies communication and focuses any parallel development toward fixing critical path dependencies.
4. Meet the team to kick off development with high spirits and shared expectations. Schedule weekly or more frequent updates in advance, and provide prompt feedback or necessary support to keep things moving smoothly and in the right direction.
5. Plan for and provide the team with your best guess of the product lifecycle, including future updates and additional uses.
6. Do not try to achieve everything with the first release of a product or service. Do first things first, keep it as simple as you possibly can, and once it is in use immediately continue to the next release based on what you have learned.
7. Relax and enjoy the process! As a team we should have fun together along the way, with clear and open communication and a bit of humor to lighten each day.

We hope these help you achieve success with future software development projects. If you have any feedback or suggestions for our approach, your thoughts are very much appreciated.

paul.houghton@futurice.com

Head of Mobile Development

Click here to download:

Customers_Role_in_Project_Success.pdf (208 KB)

(download)

Click here to download:

Customers_Role_in_Project_Success.pdf (208 KB)

Posted by Paul Houghton 

Play Scala Test Drive

Introduction

The Play framework is a fresh, agile Java alternative to bloated enterprise stacks. It focuses on developer productivity and targets RESTful architectures. On the other hand, Scala is a hot new functional/object-oriented, JVM-based programming language. It is fully interoperable with Java, but being more concise and powerful, an interesting alternative for developers.

The Play framework’s goal is to ease web application development, but the default target language is still Java. However, an alternative called Play Scala is in development, which enables you to use the Scala language for your application while keeping key properties of the Play framework. This post sums up the evaluation of Play Scala's default features, or technology choices, and lists a few alternative technologies.

The main focus is on trying things out hands-on, especially the data access layer options.

The Maturity of Play Scala

First of all, I think it’s worth mentioning that there are people (with hands-on Play Scala experience) who feel that Play Scala is not quite as mature as Play Java. That is understandable, as Play started as a Java framework and I guess Java is still the main target. Some of the key guys behind Play, like Guillaume Bort and Sadek Drobi, seem to be fans of Scala and functional programming, so I’m expecting a bright future for Play Scala as well.

Also, while writing thism I found out that Play Scala documentation is not as extensive as Play Java documentation. That will hopefully change in the future.

Play’s Google group has some discussion about the maturity of Play Scala that might be worth reading.

Data Access Layer

One of the most notable differences between Play Scala and Play Java is the provided default data access layer. Play Java utilizes Hibernate (a JPA implementation) to provide access to a database. But with Play Scala, the use of JPA is discouraged and an alternative default data access layer, called Anorm, is provided.

Unlike Hibernate, Anorm is not an ORM. It’s built on top of JDBC and uses plain SQL to make database queries. It provides APIs for parsing and transforming the resulting dataset. That may sound like a step backwards since there are already ORMs that do the somewhat laborious work of constructing SQL queries and handling the resulting dataset. But according to authors of Anorm, when we have the power of a higher level language – such as Scala – at our disposal, there is no need to have an ORM working for us. It may actually start working against us at some point (and that’s true in the Java world as well).

Even though using JPA with Scala is discouraged, some people do it anyway. But the truth is that JPA and Scala isn’t a match made in heaven. There are problems with the way Scala annotations work (although, starting from Scala v2.8, nested annotations are supported), there is no support for Scala collections, there are differences in the reflection API (I don’t know the details) and so on. See the discussion about Play Scala and JPA.

Anorm and JPA are not the only possible data access layers for Play Scala. Some people feel that plain SQL is not the best way to go and one would benefit the most by using a data access layer that uses a (SQL-like) DSL instead. For example, ScalaQuery is an API / DSL built on top of JDBC for accessing relational databases in Scala. It’s referred to as the most mature pure Scala non-ORM database access layer. Pure Scala ORMs exist as well, such as Circumflex ORM.

There is a pretty good introduction to the different alternatives on Stack Overflow: Wanted: Good examples of Scala database persistence.

Hands-on: Data Access Layer

In order to get a better understanding of different data access layer options, I tried out a few of them in real life.

Anorm felt a bit obnoxious. I really don’t mind writing plain SQL, but knowing the benefits of a DSL, I just don’t see the point. In addition, the parser syntax is not very intuitive. Obviously, you just need to learn it, but still, the syntax looks pretty off-putting. After using Anorm, I definitely wanted to try out some of the alternatives.

ScalaQuery was a step up. Installation was a no-brainer. Adjusting to it takes a little bit more time, but I like the Scala-like approach. This shows up in, for example, the way queries are built with using the for comprehension. However, the project documentation is almost nonexistent.

The approach used in the official documentation is to deal with column projections instead of objects (definitely not an ORM). In other words, whenever something is queried from a database, the resulting dataset is not mapped to an instance of the corresponding domain model(s) but to a tuple construct with a variable amount of columns. This leaves out the abstraction of mapping results to objects. However, it is possible, with a little bit of extra work, to handle the mapping, too.

Circumflex ORM: you will need to implement a Play specific connection provider for Circumlex ORM in order to use a Play managed data source. Although this is not too big an effort, it can still be a daunting task for less experienced developers.

Compared to ScalaQuery documentation, the Circumflex ORM documentation is actually quite good.

With my background, Cirumflex ORM was the most approachable data access layer of the three that I tried out. It is also probably the easiest to get used to if you are coming from the JPA world. Note that it would be good to consider using the Criteria API to avoid performance issues when joining several relations.

All in all, Play Scala with the Circumflex ORM was a positive experience. Circumflex ORM is actually being used in the project that I’m currently working on, even though we have had some issues with it (especially with Circumflex v1 and its Oracle dialect). I still recommend it.

JSON Support

Play comes with a JSON library called GSON, but according to experiences that some people have had with it, it may not be the best possible JSON library to be used with Scala. It apparently has problems, at least when dealing with Scala collections.

Fortunately, an alternative JSON library called Lift JSON is available. It comes with the Lift framework, but it’s not tied to it. In other words, it can be used with Play Scala as well.

Just before posting this, I learned that in future versions of Play Scala, GSON is replaced with a library called sjson. However, at this time I have zero experience with sjson but I'm assuming that it does its job well. After all, sjson was chosen over Lift JSON (which was already mentioned on the Play Scala roadmap) to be the default JSON library for Play Scala and I'm confident that there is solid reasoning behind that decision.

Other Features

Just like Play Java, Play Scala features a testing framework and templating engine. Both are different from Play Java: the testing framework is based on ScalaTest and the templating engine uses Scala instead of Groovy and has a design inpired by ASP.NET Razor.

One nice feature of Play is its pluggable modules. CRUD and secure, the modules that come with Play, seem to be especially popular. With Play Scala, however, you seem to be currently out of luck when it comes to those modules. The CRUD module, for example, is JPA dependent.

Alternatives to Play Scala

While writing this, I was left under the impression that Play Scala, being a full stack framework, is more complete and ready for development out-of-box than most of the Scala-based alternatives. That is, after installing Play, you just need to type “play install scala”, “play new [something] –with scala” and “play run” and you have a running web application.

On the other hand, Play Scala still seems a bit immature, especially when compared to Play Java. The documentation of the Scala version is not quite there yet. Plus, if you just need to write a RESTful backend that spills out JSON, you probably do not need all of Play’s features.

In case you are interested, here are a few alternatives that are out there: Lift, Circumflex Web Framework, Scalatra, Unfiltered, spray and Bowler.

Conclusions

Based on my hands-on experiences and comments that I’ve read from the Internet, I can pretty confidently say that Play Scala is ready for (production) use as is. However, not all the nice features of Play Java work with Play Scala. For example, when doing quick demo applications, you might miss the handy CRUD and secure modules. But then again, the power of Scala itself may compensate for the missing features when considering overall productivity.

You might want to consider using alternative components/libraries in place of some of the default ones, especially as it is very easy to take them into use with the Play’s dependency management system.

The default data access layer, Anorm, seems to do its job, but I still wouldn’t use it. I don’t quite buy the arguments of using plain SQL over a DSL. I would probably choose Circumflex ORM as it seems to be the most productive without doing too much magic under the hood. As an alternative, some of the DSLs / APIs built on top of JDBC (like ScalaQuery or Squeryl) seem to work well enough.

For JSON stuff – and I’m saying this purely based on arguments I’ve read from the Internet – I wouldn’t touch GSON. When working with Scala, simply better options are available, such as Lift-JSON or sjson.

But overall, I’m giving a thumbs up for Play Scala!

Posted by eelijokinen 

Berlin ist in

I visited quickly Finland this week to kick off the autumn together with my colleagues from Helsinki, Tampere, Berlin and London. First thing I saw in Helsinki downtown was this huge Stockmann campaign yelling BERLIN IST IN!

Recently Futurice Berlin team was strengthened by two very important people. Vera Welz started working as a HR-coordinator helping us not only to manage with the German bureaucracy but to become the best European work place and to find the best technical and creative talents while we grow in Germany. Moreover, our new business development manager Moritz Peitzsch is already spreading the word for all the interesting companies in Germany about our latest projects around mobile HTML5, Android, iOS, Qt, WP7, Web, Automotive IVI design & development, etc.

This summer was maybe not the best one in Berlin, if we talk about weather, but right now I believe that the autumn will be really hot in here :)

Sampo

Posted by Sampo Hämäläinen 

Helsinki, Finland

Reaktor Dev Day

Last Friday, I participated in a magical conference: Reaktor Dev Day. The world-class keynote speakers included Scott Chacon, Martin Odersky, and Jonas Bonér. I'm still thrilled with the event along with the subjects presented there. Additionally, the conference was very professionally organized. Thank you, Reaktor!

Below you can find some of my thoughts regarding the presentations.

Scala

I really liked the Scala and Akka introduction by Odersky and Bonér, although the schedule for the presentation was a bit too tight. Right after the presentation, I participated in the Scala Introduction hands-on session by Sebastian Nykopp.

Scala soon felt like a cosy programming language to me, as I have previously done functional programming with Scheme, Haskell and Python and also written a lot of Java. The syntax of Scala primarily reminded me of Haskell. In fact, someone at the conference said to me that in some circles, Scala is called as the "bastard son of Haskell and Java". I would rather call Scala like the Haskell implementation that has a real-world connection through many web and backend frameworks.

At home after the conference, I had to dig up some old code. Do you recognize the languages? Which would you pick as having the most beautiful syntax? For some strange reason, I like the last one the most.

map (lambda x: x*2, [1, 2, 3, 4])
List(1, 2, 3, 4).map(_*2)
map (*2) [1, 2, 3, 4]
(map (lambda (x) (* x 2)) '(1 2 3 4))

Distributed Web Systems

Ricard Vice Santos from Spotify started the afternoon with a presentation about Distributed Web Systems. Santos' act was not the best presentation at Reaktor Dev Day, but Spotify is such a hot service today that peeking under its hood sparked the attention of many conference attendees, including me.

From time to time, Santos submerged us in very deep implementation details of Spotify. However, the most interesting part of his keynote was about the multi-layered backend architecture of Spotify and how it achieves the critical low latency that a service such as Spotify needs.

Actually, the Distributed Web Systems presentation reminded me of the Google Computing Platform keynote held by Hannu Helminen in 2007. Although Helminen was a very convincing speaker, he could not elaborate the details of Google's implementation in such a detail as Santos could. Surprisingly, Santos did not have to decline in answering the in-depth questions that he was posed.

Git

A Tale of Three Trees by Scott Chacon convinced me that Git really is the best version control system out there. I had previously listened to a colleague's enthusiastic presentation about the internals of Git, but only now did I start to understand the elegance of Git's architecture based on checksums and source tree snapshots. The core idea of his presentation was the skillful use of git reset which enables a good workflow for manipulating past commits before pushing them upstream.

On top of the great content in the presentation, Chacon was by far the best speaker at Reaktor Dev Day. He spiced his presentations with due humor:

"... then you open it in your text editor. Vim if you're cool. Emacs if you're... older"

Chacon uses a presentation system called ShowOff that he has written himself. It is naturally available in GitHub.

The Business of Open Source

Chacon concluded the conference in a keynote about open source business models, some of which are used at GitHub, for example. The keynote slides are also available in GitHub and I set up ShowOff to share his Reaktor Dev Day slides on my virtual server.

The main arguments of the keynote were:

1. Become an open source maintainer (e.g. in GitHub)
2. Contribute in an open source project: send patches, make a pull request

Chacon of course encouraged us to use open source and to open source projects we are working on. Ultimately, Chacon urged us to even use some features of open source development models in commercial development as well. I think that many of the ways of working he presented are still too idealistic to be used on a large scale, and might not be successful in the projects and with the clients that I've run into. But without a doubt, some of them could work and are should definitely be considered – especially when a new project is starting and the ways of working together are being built.

Chacon's presentation reminded me of Jon "Maddog" Hall's inspiring Linux evangelization that I was able to attend at the Helsinki University of Technology in 2003. While reflecting these two presentations, I realized that social media - such as GitHub - is the most important change in the ways open source is being distributed and developed during these 8 years. Another significant phenomenon is the evolution of distributed version control systems (DVCS). In 2003, there was no DVCS systems nor GitHub and Maddog concentrated on how to use and distribute the lower level open source components starting with the Linux operating system.

The use and significance of open source has been continuously growing. The open source community is using the "social DVCS media" for self-organization in a whole new way. You just need to carry out the Chacon's core theses to catch this train.

Posted by Yrjö Kari-Koskinen 

Privacy is a techie problem… isn’t it?

Last week I gave a presentation at OtaSizzle project’s workshop on privacy. OtaSizzle is an initiative for building a living lab and services on four campuses around the world. Social interaction and related privacy questions are at its core. Here is a short(ish) version of my talk (although with a conclusion I wrote specifically for this blog).

Which is worse: having your credit card stolen and used, or having a photo of you half-naked and drunk publicly available on the Internet? If presented with an option to choose between the two, most of us would rather have our credit card stolen than have a (presumably) unwanted photograph of ourselves in the web.

Embarrassment, losing face, and damages to our reputation are the kind of privacy and security threats we are all familiar with. We have seen and read about social blunders on social networking sites (e.g., forgetting that our mom/boss/ex-spouse can read our status updates). The tabloid newspapers have also found social media to be a goldmine in getting access to private information about the social life of public figures and celebrities.

From the point of view of computer security and privacy protection in the cyberspace this change is fundamental. Traditionally, computer security and privacy has seen the most common threat to ordinary citizens being a malevolent third party hacking into bank accounts and credit card numbers. However, in the age of Facebook, the privacy and security threats people are more concerned about come from our friends, family, friends-of-friends, acquaintances, and their networks. How to protect ourselves from a relative who keeps on posting embarrassing baby pictures? What kind of a firewall can save us from friends who share all photographs, tweets, and status updates with the whole world?

Virus protection, secure protocols, P3P, and other tools from the computer security toolbox are impotent in the face of social media privacy threats.

To make matters even more complicated, we really can’t predict what kind of privacy risks and problems future technology holds for us. The Helsingin Sanomat Kuukausiliite (8/2011) had an excellent column: the journalist was killing time at a café looking at expensive cars, typing in the license plates into a text message service to get the name of the owner, and then googling who they were (and probably using Facebook and LinkedIn as well). Quite easily he was able to get basic information to amuse himself in the sense of “a-ha, so that kind of a person owns that kind of a car… and there he walks away from his car”.

The thing about this mash-up technology is that no one ever designed it as a whole. Nobody ever sat down, planned, and implemented such a service. Rather, the clever journalist only combined common and easy services together. And he was probably not the first one to amuse himself and others with this idea. But because the combination was emergent rather than specifically designed, it just points how difficult it is to predict what the bits and pieces of services and open databases enable tomorrow. Services are like Lego blocks and practically anyone can put them together to make something new. No crystal ball can anticipate all possible combinations and the privacy issues related.

With these two points in mind (a. traditional computer security is impotent, and b. future mash-ups are impossible to anticipate) few questions push themselves to the front row: Can the privacy issues in social media be solved with more computer science and engineering? Are we building technology to solve problems originally created by technology?

To answer the first question: No. The concept of privacy captures so much of our lives that applying solely scientific and/or technological approaches to it is simply silly. Privacy is one of those topics that shows how computer science and engineering has to change and adapt to influences outside its comfort zone, such as social sciences, humanities, and legal studies. Nevertheless, go ahead and google, for example, “privacy as a service” and you get 2 billion results trying to use computation and engineering to solve the problem.

To answer the second question: Yes. We live in a society where technological advancement is intertwined with continuous economical growth, and our way of living relies on the latter, and hence, we rely on the former as well. In other words, continuous technological change is integral to our society and culture. To sustain that, it is actually kind of comforting to think that we will never run out of requirements and needs for new technologies, because the old ones are prone to create the need for the new.

To wrap this up: Yes, the geeks will inherit the Earth (i.e., the technologists will have a growing influence in our society) but the geeks need to open the front door and let in lots of new people with fresh new non-technological (and dare I say antipositivistic) thinking. And once the geeks embrace the non-techies, perhaps our future is not written solely by engineers and scientists.

Posted by Risto Sarvas