How are you, Hannu?
I’m okay, thanks! The consulting assignment I worked with for over six months ended in late January. We created a Minimum Viable Product, and now others are in charge of the development process. The project was extremely interesting, but then after a long work period and the holiday that followed, I’ve had the opportunity to focus on the things that were left unattended during this intensive assignment.
What do you do at Frantic?
Title-wise, maybe ”solution architect” is the closest to what I currently do. I design and develop different applications and information systems in different scales from tiny to huge ones. The development part means basically coding, and when it comes to that, I’m interested in everything. I’m not visually particularly skilled, but aside from that, all development is fine by me. Often, I get assignments of a slightly larger scale, like defining the architecture and ways of working instead of individual functionalities. If I develop a functionality, it’s usually an integration to another system.
What kind of problems do you solve?
This is actually kind of a difficult question but I, on my part, try to model the client’s business – both the existing, and future – into an information system while maintaining hold of all the most important details. Storing information, processing or moving it to other systems are the big building pillars of the solution, like in architecture. Most of them you can decide about on your own, but especially in integrations you must work with what you have: as one end is already attached somewhere, you just need to find the best way to adjust the other end.
How did you become a developer?
I became a developer mostly because I like to build things. As a child I loved legos, and they were awesome because the building blocks were already there when you started building. I liked whittling pieces of wood as well, but I was never very good at it. If you can’t see that tiny wooden sculpture in your mind’s eye it’s hard to have a reachable goal with wood-carving. Maybe with better hand-eye coordination I could’ve become a carpenter, but my strengths led me elsewhere.
I’m relatively good at math and languages, so I started building things in my mind. Development is, essentially, constructing things in your head and then modeling them as code. So, I think that some knowledge of and interest in logic and languages, as well as the ambition to build, and a love for consistency, are my most important motives for becoming a developer.
I started actually coding when, as a third-grader, my parents finally gave in and bought me a computer so I could write my first pieces of code. They weren’t very complicated at first, but slowly 30 years have passed by. The first years were, of course, playing with code without any actual perseverance.
I actually started to deepen my knowledge when I started studying computer science at the university. After a year of studying, I took up a summer job. After that, it’s just been learning. There’s no end to learning, which probably is one of the reasons why I love this field so much. Simultaneously, I have gained a lot of a more profound basic understanding of code, in addition to smaller individual technologies, many of which have already been forgotten.
What is the most challenging part of your job?
Learning is of course always a challenge, but it’s such a crucial part of this job that I don’t really want to view it as a separate process of first learning and then applying that to something. Usually, you just have to learn as you go, as most things we do as developers are more or less unique. Even if someone has created similar solutions in the past, no one has done exactly the same thing – and if they have, it would be idiotic to recreate it.
What’s the best thing about your job?
I always want to look at this from the end-user’s perspective. It’s amazing to be a part of creating services that make things in life significantly easier for the end-user. That makes me feel good.
It’s also fun to think about abstract things and discuss them with a colleague. We’re building something you can’t see but doing it together. There are more than one of us inner carpenters working here.
In your latest project you lead the development team of the client. What was that like?
We created value-adding services for the biggest second-hand car sales marketplace in Finland, nettiauto.com. I was involved in mapping out the technical guidelines of the projects, for example, the choice of technologies and architectures, as well as work practices within the given frames. Even though the service we provided is separate from nettiauto.com, we took into account some consistencies in the architectures to achieve certain synergy aspects. As it often goes: an existing product helped form something new.
In our team, I had an especially good opportunity to have a say on one hand in what we do, where and what technologies are used, and on the other hand how the inner architecture of the service is built with these blocks. Even though we are used to reviewing each other’s code anyway, I also wanted to make sure that nothing anyone wrote was against the architecture I had planned.
My goal was to keep the code simple, easily testable and easily tweakable to ensure that when situations change and new needs arise, the architecture wouldn’t be in change’s way. Of course, it’s not a good idea to spend too much time thinking about something that might never happen, but once you know what’s coming, you should have at least some sort of plan thought out. In this way, my job was also about the balance between the present and the future.
How does leading an external team differ from leading a team in Frantic projects?
Well, at Frantic I work with people I know, and when I’m consulting, I need to get to know the people in addition to new technologies and fields. As a Tech Lead you also have to know what sort of assignments should be given to whom. That depends on each person’s individual skills and interests, but you also need to make sure that everyone knows enough about each component in the project in order to ensure that no crucial information escapes with one developer. The project should be able to run and move forward regardless of who is working on it.
Another big difference was the fact that in this project two developers were working from all the way in India, and I never met them in person. In an open source world this is not unheard of, but for me, it was new to work so closely with team members I have never met.
You’re a strong advocate for agile development – what value does it offer a client?
I think a client should always ask for agile working, and the more the client commits to it, the more useful agile development becomes for the client.
The benefits of Scrum are, in my opinion, a direct result of combining the principles and framework of agile development with timeboxing. As changes in software technologies are quite difficult to predict, Scrum doesn’t even attempt to foresee anything past each sprint. But in cases where there’s no business profit to gain from predicting anything, Scrum is useless. Also, according to the Lean principle, it’s a waste of time. There’s no point in making estimates if they are of no value to anyone.
The much more important thing is to do whatever is the most useful and attempt to tackle risks beforehand. A good development model is to think of a budget and start planning what to do based on 1) what creates the most profit and 2) what holds the most risks. If something is deemed risky, it’s a good idea to take those risks as soon as possible, to have more time to react to them.
What should clients know about this field now and in the future?
The client should know their business through and through and be certain of what they want to achieve. Then they could trust others more in helping them reach their goal. Not entirely but letting them offer their tools and expertise in the “how”. The client can show the way while others do the work.
We offer a wide variety of other types of expertise besides transferring a thought into a technically functioning web service. We also offer help in planning and designing, not just the creation process. We always want to hear the client’s thoughts about their business and work out together what kind of services they need and what can be created to support the client’s vision.
---
Are you thinking of reinforcing your team with a select few external experts? Do you wish to create a multi-production team to support and lead the development of the digital customer experience? We would happily allocate our project management, design and development experts to help with challenges related to digital business, project management and the concrete implementation of customer experience. Our Consultancy Business Unit Director Maija Typpi-Häkkinen would be happy to tell more. Contact us!
