Blog

System architect is a person who misses the code. Ha! Surprised? I don’t think so. If you are an architect like me, you probably feel this longing. Smaller or larger, but somewhere subcutaneously, admit it, you miss coding, don’t you?

As a QA, I have to admit the last day at work before holidays is a disaster. But it is not as bad as when I am sick and I’m not able to work at all for a few days. And that is a complete catastrophe! Is there any way to deal with QA absence?

As software developers, we write code which falls into one of two categories. The first one is the business logic code – the essence of the software we create. The second one is infrastructure code – a backbone of the application. Did you ever think what is the optimal ratio between an amount of code in these two categories? In this article, I will share my observations on this topic. Small side note, in the course of this article I will use term BICR to denote Business/Infrastructure Code Ratio.

It would seem that a good choice of technology is the basis of a good project. It would also seem to be a simple choice. Nothing could be more wrong. Read on to see how you can go wrong and suffer from unnecessary costs through a lack of a proper and accurate analysis of business assumptions and MVP.

Test automation is seen as the next step from manual testing on the test development path. The popularity of such solutions and the positive associations they invoke (eg technological advancement) prove their universal demand. However, before implementing this solution at home, it is worth considering what automation can really give us, and what we will not achieve thanks to it.

IT companies are paid for developing. What the client is buying is the labor of developers. What’s the trick to picking the right team? This is a vital issue that should be considered by the client and company together at the bidding stage. In IT companies, two models of the settlement are used: fixed price or time & material. Read on to learn more about choosing a form of settlement.

Stefan Moritz, a well-known service design coach, said: „80% of companies believe they deliver outstanding value and a superior customer experience, but only 8% of their customers agree.” Let’s find out how to be a part of that 8% group. Regardless of the role, we play in a project.

Your phone is filled with a lot of applications. Everyone has, uses and knows them. They are useful and no one can do without them. Mobile applications occupy the memory of our smartphones, requesting updates. In addition, they can slow down and often break down when there is no direct access to the Internet.

Each of us Testers has at least once met someone who has asked this question. As well as asking why automatic tests are needed in a project at all. And so begins the arduous task of convincing the skeptic. Let’s not beat about the bush – the fact someone would ask such a question shows how little they grasp the topic. Read this article about automated tests.

As the agile methodology and object programming had made their way to the minds of the non-programmers, the Domain Driven Design is still a foggy term. Yet, it may be the best way to handle the most significant and most complicated IT projects. The concept of Domain Driven Design was born when Eric Evans published the book of the same title.