Goddamn salespeople

Each and every one of us has probably dealt with some type of “salespeople”, be it phone salesmen, insurance, car sales, B2B sales etc. And you’ve also probably formed some sort of stereotype of what a salesperson is like, based either on your own experiences or maybe urban legends. A common (mis)conception, especially in the software business is the classical “over-promise under-deliver” concept. Sales is seen as a problem, always promising customers things that can’t possibly be delivered in the promised time frame. Communication, education or motivation can be some of the reasons behind the issues, but overall it creates an unfortunate circle of negativity. I’m fairly glad that I can honestly say, that this is not the case at Gofore.

Transparency is key

Generally judging something or someone without researching and understanding necessary background information and facts is just plain stupid. Quite a lot of information is open at Gofore, either by just browsing to the appropriate site in Confluence, or dropping a question in Slack to an appropriate channel quickly gets you the information you need. So during one of the (occasionally rather heated, I must admit) sales-resourcing discussions in Slack, I said that it would be interesting to see what a day in a sales role looks like, to understand better how it works. 10 minutes in, and we’d agreed on date with one of our Lead Consultants, Ville. Agile, yeah!

A day in the life of


To understand my point of view a bit, I’m the guy at the customer’s office, wearing a hoodie and noise-cancelling headphones trying to solve various problems with code, happily unaware of the world around me. Guys like Ville handle everything to make this possible.
So heading to meet Ville on a rainy Thursday morning, I had no clue of what to expect of the day.

 9:03 am

Meeting Ville at a Café in Pasila. Ville goes through some of the responsibilities in his role, keeping existing clients happy, providing them with the help and resources they need, acquiring new clients, creating offers, development of a certain industry segment… Quite a lot of stuff. I ask questions and try to get a better understanding of each area of responsibility, but the entirety is not easily understood over a single cup of coffee.

9:40 am

We’re joined by Terhi, another one of our Lead Consultants. We start making our way to the first meeting of the day, a steering group meeting with an existing customer. For the duration of the walk, Terhi and Ville discuss about the situation at the customer, and I start getting an idea of what the meeting is about.

10:00 am

Meeting the customer. Everything discussed here is confidential, so can’t share any of it. What I can say though, that I’m very, very happy that we have people dealing with these kinds of meetings. Even the more sensitive stuff is dealt with in a very professional manner from both sides. Heavy, complex stuff, that, I can say, my Python skills wouldn’t be able to solve.

11-12 am

Making our way back to Kamppi, so we’d be closer to the next meeting in the afternoon. Also, lunch.

1:00 pm

Going through a fairly large public tender, and the current status of the planned offer. Gathering the needed amount of references and all the required information about them, filling up the required forms in exactly the correct manner, finding suitable people to fit the requirements, gathering their CV’s etc. Tons and tons of work, and this needs to be done by tomorrow? Why of course. Also, interesting to see, that at this point it’s been decided to not participate in a part of the tender that would include some, how to put it, hairy tech. As we go through the process I’m also seeing tons of potential for automating parts of the process, to save hours of time. Won’t help for this offer though, as the timeline is so tight. Again, I’m fairly glad that we have pedantic people taking care of these, as it would be a complete mess with my patience and organizing skills.

1:40 pm

We start heading to the next meeting. An existing customer has invited us for a visit, as they have a fairly fresh project going that they would need help with.

2:00 pm

Customer is clearly excited about the new project. He enthusiastically explains the current state and the plan of the project, and I’m starting to get excited as well because we’re apparently dealing with a fairly tech-savvy guy here. Ville is making notes with such a speed that it seems like he’s capturing every word of the requirements on the first go. I’m starting to hear terms that I really like: Cloud, Scalable, Docker, AWS, GCE, REST, React. I can actually take part in this conversation, and I give some comments on the architecture and technologies. Yay! I did something!
We end the meeting on agreeing how to move forward, how to deal with the bureaucracy and when should the needed experts start. Sounds like a very interesting project, I very nearly volunteered myself!

3:00 pm

We end the day by having a beer and going through bits of the day. Honestly, I’m pretty beat and my head is spinning with all the new information. Lot’s of stuff outside my comfort-zone, but I did learn quite a lot. Ville’s day is not over yet though, as he still has to finish the offer for tomorrow.

Afterwords

I’m pretty happy on how the day turned out. With an open mind and zero expectations, I had a great time and now understand a bit more on how sales works.
Any time you’re having a hard time grasping someones side of an argument, try hopping in their shoes for a day, and it might help you to understand them a bit better. Especially in case you’re working for the same business, you’re very likely to have similar goals in your work i.e. for the company to succeed and people to enjoy their time there.

Avatar

Lauri Kuittinen

Lauri is a System Specialist at Gofore, working mostly with DevOps- and automation-related tasks. Word on the street is, that he has been involved with actual Software Development as well. In his free time, he can usually be found at a climbing gym or outside trying to get on top of a boulder.

Linkedin profile

Do you know a perfect match? Sharing is caring


Is Angular 2’s state management magic eating React alive? Is React better suited to mobile environments than Angular 2? What if I am just a newbie coder and need to choose between the two?
Two full-contact Javascript professionals Henri and Roope are here to share their secrets. So let’s get into the ring and find the next Javascript framework champion! Feel free to read the introductory, more general Part I as an appetizer.

Fast, faster, Angular 2

Q5: Are there any big performance differences between Angular 2 and React?
Henri: Performance-wise there’s not much of a difference between React and A2. Performance used to be a bit of an issue for A1, but A2 is pretty much on a par with React when it comes to perf.
Roope: Even the initial release of Angular was already faster than React in many cases thanks to its highly sophisticated change detection mechanisms. Angular is also a very young technology, and is continually evolving performance-wise. Angular’s subsequent releases have already brought extra improvements to performance. Also, at the same time it offers excellent performance, it makes it extremely easy to manipulate the state by using a library called zone.js.

Q6: Is the bundle size going to be an issue for React/Angular 2?

Henri: For a React-based app, it depends entirely on your build configuration and the number of dependencies you’re bundling along with React. React itself is just a view library and doesn’t hook into your build-time bundle generation process in any way.
That being said, react and react-dom together weigh in at around 40 kB (minified and gzipped), which is definitely not too much for the majority of use cases.
Roope: Angular comes with ready-made bundling with Angular CLI. Thus you don’t need to spend your valuable time adjusting the builds and reinventing the wheel again and again. Instead Angular CLI provides you an easy to get started sample project along with code generation features besides the obvious highly optimized building and bundling for production. Angular’s architecture with TypeScript and Ahead-of-Time compilation allow it to skip every single not used thing from the bundle.
Since React itself is also relatively small, I don’t see that bundle size would be concern for either. The bundle sizes of course depend on what all you include and thus the comparison in actual size does not make that much sense.

Thick and thin React

Q7: Which technology has a simpler state management implementation?
Henri: As React is just a view library, it only concerns itself with component-level state. Application-level state can be managed in a number of ways at other layers of your application architecture. At the time of writing, the most popular state management solutions to be used in tandem with React are Redux and MobX.
Generally, the complexity of your state management layer should be no greater than warranted by your application’s requirements. For simple apps React’s component-level state might be enough, which is hard to beat as far as simplicity goes. In the majority of cases, however, you are probably going to need a separate state management library. Of the popular two options in the React ecosystem, MobX is simpler, easier to get started with and less opinionated than Redux. On the other hand, Redux gives you a proven state management architecture that might scale better as the size of your team grows.
In the end, the simplicity of your application’s state management layer comes down to the requirements. The view layer, whether it be React, Angular 2 or something else, should not impose any significant architectural constraints when it comes to application state management.
Roope: Angular provides no limitations on the state management. That said, it provides you with an easy solution for some common, basic needs with services. Besides the services, you can easily add the very same Redux from the React world, or use the more user-friendly @ngrx/store which combines the reactive programming library RxJS along with Redux concepts. This allows you to write more elegant code with the knowledge you might already have from earlier Redux usage.
Q8: Let’s say that you are a newbie programmer. Which technology has an easier learning curve?
Henri: Compared to Angular 2, React has a way smaller API surface and less custom syntax to learn. This, coupled with the fact that A2 developers usually have to invest some extra time to learn TypeScript when they get started with their first Angular project, gives Angular a steeper learning curve as compared to React.
It should be kept in mind, though, that Angular gives developers a lot more out of the box than React does, which makes this comparison a little unfair. When it comes to building a full, nontrivial application with either technology, Angular might be easier to pick up for a total newbie as compared to setting up a similar React-based stack and deciding between the various alternatives for routing, state management and backend integration.
Roope: Angular is often mistakenly taken as hard to learn. After giving dozen of trainings on Angular & TypeScript I can assure you that it is not the case. Angular is divided into modules elegantly and the core itself does not have a lot to learn. The components are easy to understand and templates only have 5 well-declared additions to plain HTML.
As compared to React, where you usually first need to adapt the JSX language the templates are just simpler to understand and require no special knowledge about Angular to be understood by anyone with prior knowledge of building modern web applications. Also the same syntax can be more or less found from Vue.js, though the syntax there is a little more hazard.
Also, since TypeScript is very friendly in that it does not enforce you to type everything from the beginning, you can get up and running with Angular straight away without getting to know TypeScript. You just get all the benefits, including code completion for all library code and static error messages for all of your templates and other code.
The last point, but certainly not the least, on this topic is that starting to build an actual React application (not some pet project) requires you to choose dozens of libraries to support you. You need to, for example, choose libraries for the following concerns: routing, state management, testing, test runner, bundling & minification, http requests, form handling, server-side rendering, typing. Angular has a great solution for all of these already available, but as you can read in my earlier blog post, titled Angular is not a massive monolith – but your mom is, this does not mean you couldn’t use any solution you see suitable, but instead you can modify the Angular anyway you see suited.

we are hiring

Is Angular mobile?

Q9: The whole world is going mobile. How will React/Angular 2 respond to market demand?
Henri: The traditional React way to go mobile is building a platform-specific UI layer for Android/iOS with React Native while reusing the code at upper architectural layers across the target platforms. This, in my opinion, is a very sensible way to go about code reuse across different platforms as it allows you to craft a quality UI for each platform using the platform’s native UI components while still being able to reuse the parts of your code that back the UI.
Another, more bleeding-edge approach to going mobile is building a progressive web app, something that Google has been actively promoting for the past year or so. While some browser vendors have been holding back in implementing PWA essentials like the Service Worker, it still looks that, in the medium term, PWAs will become an attractive alternative to traditional mobile apps. Obviously, you could build a PWA using any view library, such as React, as the Service Worker sits way above the UI layer.
Roope: On mobile world, there are three suitable options available. The first and most important one is the Apache Cordova approach where your web application is packaged as mobile application running on top of the native WebView available on a device. Apps will also have access to all native APIs such as Bluetooth and camera via plugins available. This allows you to write your code with familiar technologies and develop in faster iterations on the browser as well. With the performance of mobile devices these days, Cordova is really the best solution assuming that you aren’t making a game with extremely high performance requirements. To support this with Angular there is a framework called Ionic 2 which provides a set of ready-made Angular components that work on supported platforms (iOS, Android and Windows Phone) as they would be totally native.
If you are fanboy of React Native, you might be happy to hear that as a second option Angular also supports usage of React Native with Angular React Native Renderer. This way you can utilize the ready-made UI components of native mobile platforms. Development with these is a little bit of a hassle, but can be managed and you can rely on all of your UI elements to behave exactly as native components (since they are). There is also another framework called NativeScript which plays even better together with Angular. These frameworks are also a viable option for mobile app development, especially if you don’t have tight schedules or budgets.
The third option are progressive web applications. These are built on top of web app manifests and service workers, which both still lack the support of some major browsers (Apple’s Safari & mobile devices and Edge). They provide an interesting middle-ground between native applications and web sites by providing features such as offline usage, native API access and desktop installable icons. Luckily Angular provides out-of-the-box support for these too via a project called Angular Mobile Toolkit.
As Google has emphasized many times during the release of Angular, it is more of a platform than just a framework. These are all examples of this approach. Angular provides seamless support for all of your needs whether they are for mobile, web or desktop applications. This is one the greatest points of Angular ecosystem.
Q10: The ecosystem around either technology is an important consideration. Which one has the upper hand here?
Henri: Both Angular and React have strong and healthy ecosystems and I don’t see them dying down anytime soon. React, having been around longer than A2, has a head start here, meaning that there are probably more alternatives for React-based apps than there are for A2 apps. Angular users, on the other hand, can also use some of the existing libraries available for A1, provided they have been updated to support Angular 2 as well.
Roope: It is true that React ecosystem has been around a lot longer and has more possibilities available. Still the amount of libraries for Angular is just huge and I’ve never had a situation where I would need a library for certain thing and it would not be available. One important thing here is also that since Angular does not restrict you that much, you can re-use many of the libraries originally made for React world.

Choose a life. Choose a job. Choose React. Choose Angular 2. Choose a life.

Q11: What if I need to get shit done in very little time — like one month? Should I choose Angular 2 or React?
Henri: That would depend on the composition of your development team. If you have a bunch of seasoned Angular veterans with very little exposure to React it would be a no-brainer to go with Angular. Then again, if your team has very little experience building web apps with either technology (or has lots of experience in both A2 and React) the decision comes down to whether you need to use any 3rd-party libraries, and if so, which one has better alternatives to meet your requirements. Other things being equal, it’s a matter of personal preference.
Roope: It, of course, depends on your specific needs. For quick and simple projects I could go with Vue since it already has all the core pieces available and otherwise is as lightweight as React. Vue also has the Vue CLI to generate everything necessary for you.
If you instead are going to build a more sophisticated application, I would definitely choose Angular. The main reasons for this are the ease of getting started with enterprise-grade application architecture that includes, for example, routing and form handling, extensive library support and seamless entree for new developers to the application since the core concepts are always the same. Also, performance will still be top notch and Google’s backing of Angular is an important consideration.
Q12: What if I have an application that will require dozens of developers and years of active development? Should I go with Angular 2 or React?
Henri: What matters more here is consistency in architecture, design and coding practices and how well you’re able to enforce them through your project’s toolchain — it’s not so much a question of which ecosystem to bet on since both are well-established and will probably be around for quite some time.
The one advantage, however, that Angular-based projects might have here is that they’re usually written in TypeScript, which really comes into its own in collaboration-intensive projects when compared to plain JS. Then again, you could just as well add TypeScript or Flow to a React-based project, so in the end, it essentially comes down to having a well-thought-out toolchain in place to support your development workflow.
Roope: This one is a no-brainer. Angular is the obvious choice. Why? For really many reasons. This is where Angular really shines. Besides it being easy to get up and running with Angular, it also has a solid architecture for larger applications built-in. This, along with the extensive style guide enforced by the Codelyzer TSLint plugin, provides a solid structure to build on top of. It also makes it sure that any developer who knows the basics of Angular can just jump into the project and be productive immediately.
One important consideration here is also the usage of TypeScript. As you probably know TypeScript provides a flexible static typing system on top of JavaScript. It allows IDEs to provide better auto-completion, analysis and other useful stuff along with support for more sophisticated refactorings to be performed. Even though debatable, I’m a big believer in the benefits of static typing for program correctness and have been able to see the gains in action on a project where we have been building large-scale Angular application for over a year with a dozen developers.
One last thing is the fact that Google backs it up and also depends heavily on it in its own huge applications. Thus the support will be around for quite some time. Also, the roadmap for future releases is quite ambitious. This, compared with Facebook’s backing of React, feels a lot safer. Facebook can’t grow forever and as we all know, the market for social media is constantly changing. If something would happen, supporting the React ecosystem most probably wouldn’t be the top priority for Facebook.

Last words

Clearly, Angular 2 and React are the two sides of the Moon. This blog post shows only a fraction of these two awesome frameworks. And as always, the ruthless but fair developer community will have the final call.
For a wannabe coder like me, this journey has been remarkable. But real heroes are Roope and Henri. It’s amazing to see your passion and knowledge of real software development craftsmanship. You are today’s wrestling stars!
 
Author: Juhana Huotarinen
Experts: Henri Heiskanen & Roope Hakulinen
Graphic design by Ville Takala

Gofore Oyj

Gofore Oyj

Do you know a perfect match? Sharing is caring

The Sweet Spot of DevOps

We’ve been blogging about DevOps earlier. We’ve done tons of DevOps projects. Still, it seems that the big DO-wave has just started to rise. This blog reflects from the ideas of the doctoral thesis by Marko Leppänen: Vanishing Point: Where Infrastructures, Architectures, and Processes of Software Engineering Meet and its references. If you feel that you need more than what this blog has to offer, then it is time to get serious and learn from the awesome thesis of Dr Leppänen.

Picture 1: Artistic impression of the DevOps wave gaining momentum

Fast, cheap and realiable!

We all know the holy triangle of software project management. A certain scope of features delivered in a certain time produces a certain cost. Fast release means less features. While business needs to follow a fast changing business environment, long delivery times are unacceptable.

Need for speed has produced Agile methods

In Agile, small feature increments deliver constant value stream in a form of new software features. Small increments ensure a continuous value stream, enable a rapid feedback and create a tighter co-operation with the customer. A dream come true.

Picture 2: The holy trinity of project management. You may visually think that the triangle must stay equilateral or you loose quality. “Cost” may be also tought more generally as resources. And “Requirements” as value produced.

Continuous Deployment

Continuous Deployment minimizes the overhead related to software integration, testing and installation. While it becomes possible to add and remove features easily from the live product, it enables the real end-users to experimentally define the real value of the features. Fast release cycle requires adequate maturity level of DevOps. The maturity level is defined by the overall execution of Process, Infrastructure and Architecture.
OK, sounds like a plan. I wanna be continuously agile. How hard can it be?

Speed is pronounced P-A-I

For the rapid increments to work, all the additional overhead needs to be minimized. In other words, everything must be automated. That means tons of tools. The software architecture itself must support incremental releasing. So, you need a modular architecture. In other words, Continous Deployment requires a combination of process, architecture and infrastructure decisions.
Picture 3: Can you find the sweet spot of DevOps from the picture with three bubbles?

Process

Process can mean anything. Here it means people and ways-of-working. You need the people with the right skills and the right mindset. And you need to empower them. When you have the right people, the process acts as a catalyst or blocker. In other words, you need ability from people and Kaizen from processes.
I’ve divided the Process into sub-chapters titled Culture, Testing, Decisions, Crossfit and Measure. Before going into those, let me draw you a pie diagram about it. OK, let’s make it two.

Picture 4: People pie lists the ingredients of personal ability. Process pie describes the Kaizen style continuous improvement. You need both, but start with people. If you’re gonna have only one pie, please make at least sure to make a double crust apple pie.

Culture

Organization ensures that someone has knowledge and authority to take care of all the functional areas of the software development. Stuff like requirements and bug tracking, development, testing, deployment and quality assurance.
There will be cross-functional roles and independent roles. For example, architect versus quality manager, as well as developer versus tester should be independent to avoid bias. Similarly, operations requires different mindset compared to development. You don’t need much of old school organization structures, but clear roles and mandate to act.
A situation where people do not have opportunity to coordinate, collaborate, or cooperate their work is called social debt. It is a parallel for technical debt at the organizational level

Testing

In agile world tests are often developed even before the actual functionality. Integration and testing is being executed automatically, triggered by push to version control. This requires some infrastructure and tooling. But first of all it requires the right mindset. You need to include testing into development.
High speed of development is not enough alone, as the development also has to have a direction and quality

Decisions

Decentralized decision making enables timely and effective decisions. This is a form of minimum viable management, where the decisions are made based on collective intelligence. In the knowledge work there is often a need for timely decisions on complex subjects. In such environment, the only timely and precise decision method is based on collective intelligence.
In the complex domain there are no right answers. Therefore, one needs a safe-fail environment

Crossfit

Cross-functional people enables flexible resourcing and fast decision making. Individuals are able to support each other on their assignments. “Anyone” can take over anyone else. This kills hierarchies and siloes, enabling wider scope of information, decentralized decision making and transparent ways-of-working. Cross-functional consists of both skills and attitude. Attitude first, skills will follow.
“Social developer” is an overarching concept, where tools, methods, and processes must be in line with each other

Measure

Metrics are collected automatically by the infrastructure. Metrics are used as a base for decision making. Metrics force continuous improvement. Metrics enable fast and timely decisions. In DevOps world the production environment metrics describe the value of existing and newly deployed features.
Increased situational awareness caused by the quick feedback improves developer motivation

Infrastructure

The nature of the tools used for development, testing and deployment depends widely on the domain, technology stack, legacy and user preferences. Still, a continuous deployment pipeline from coding to deployment is required. Process and infra are interrelated, while infra is used as means to automate and speed up the processes. As you know, culture beats strategy. So, for example a cloud strategy is useless if the people disagree.

Infrastructure and process are interrelated

Architecture

Architecture depends on the chosen tools and technologies. I’ve divided Architecture into sub-chapters Modular and Deployment. There is a reason I’ve taken the Deployment (infrastructure) chapter under Architecture. Keep calm and read on.

Modular

Code produces the functionality of the system. Architecture acts as an enabler for the non-functional requirements. Combination of these two can be thought to represent software quality. ISO classification for software quality follows functionality, reliability, usability, efficiency, maintainability and portability. Inside-outside division of the quality means that quick-and-dirty implementation of an external feature creates technical debt inside the code. Technical debt slows the future development. On the other hand, debt can be seen as a resource, which helps to cash in valuable features faster. However, payback is inevitable. Most common form of payback refactoring. Automated tests are the only way to ensure that the payback flows the right direction.

Technical debt leads to inaccurate time estimates and speed makes the technical debt visible

Deployment

Technology selection is an architectural decision. There is a clear connection between the selected architecture and ability for fast deployment. The power of agile comes from small incremental and iterative updates. A live installation is a sign of the done requirement. In Lean terminology all the non-live code can be seen as inventory and waste. After the continuous integration works, the next logical step is continuous deployment. Operations isn’t a separate of Development but a logical continuum. Here comes the big ideological step to treat the environment as a part of code. In DevOps development quality assurance and operations form a holistic approach.
Here’s a cool old-school picture presenting the logic of DevOps. Yes, it’s old school while only the PO is having a beard.
Picture 5: DevOps big picture.

Continuous * (everything)

Continuous * provides numerous benefits. Fast delivery feels good at the both ends. Quick feedback increases situational awareness. Flow and visibility increases the developer and stakeholder motivation. Continuous * focuses the communication on what matters most. End users are measured on real-time, so there’s no need for error reporting. Developers can just commit, no need to inform anyone. Automation takes care of the process. Business owners dare to try new ideas, while proof-of-concept implementations are fast to deploy and self-evident to measure. Failing is fast and safe. Everybody are Lean and beautiful.

Five cents

Remember PAI. Process, architecture and infrastructure are interrelated.
1. Have a well-automated deployment pipeline that is fast to setup
2. Have identical production and development environments (that are fast to setup)
3. Use fast communication and feedback channels
4. Be Lean
5. Don’t use the domain as an excuse. Speed is a state of mind
 

Jari Hietaniemi

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Do you know a perfect match? Sharing is caring