Blog

As a rule, it looks like most of us don’t think about how to build a development team. The team is just there. There are several developers, sometimes a tester and they form a team… only in name. However, are these people really a team? Real teamwork is really a fleeting matter. Unfortunately, organizations often fall into traps that don’t allow them to achieve teamwork within their dev teams. How to get out of the impasse? Read below.

Some may ask: what is the point in doing code review if we have automated tests? Let me ask differently…what exactly do tests test? Is the app correct? Or whether the app has errors? My answer is: tests can only help us know if the app has errors. Tests alone, don’t care about the quality of the code.

I have already written about the art of communication with business here. However, the ability to communicate is one of the basic skills of the system architects. Actually, how else can you make a good system without prior, good understanding?

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.