Some product development teams might fall into the trap of thinking that all customers need the same thing. However, an outstanding vendor should cultivate a mindset of sharing and exploring which ideas would work well for each particular product, and which wouldn’t. Today, with the growth of agile methodologies and DevOps practices, companies that choose to outsource the development of their software increasingly prefer a product mindset. This allows vendors to individualize their approach to outsourced software product development, deliver results that would best meet market and client needs, and ensure more flexibility throughout the development process. Let’s see how the product mindset differs from the project mindset, and learn how to find out if your potential product development vendor has it. Project mindset vs. product mindset The project-focused approach revolves around a predefined scope of work, strict time frameworks and compliance with the initial plan. In terms of the project, the vendor is mostly concerned with allocating resources more efficiently, spending less while doing more. In this mindset, project managers approach the project as a process that must be followed strictly, and their attention might be diverted from product specifics and actual user needs. In contrast, the product mindset is all about critical thinking, which helps correctly define the product goal and map out steps to success. The approach begins with defining goals and visualizing the customer’s problem or need. Focusing on the customer’s requirements will help the vendor guide the design and development efforts of the team in a way that optimizes time, resources and project outcomes, which is a win for both sides. In product development outsourcing, creating value for the customer and making this value available and easy to tap is paramount, while constant customer feedback can be used to help evaluate the results and estimate the degree to which the results align with the product delivery objectives. As you can see in the diagram shown, development patterns of a vendor with a project mindset are predictable: the whole process is broken down into small chunks, depending on time, budget and resources. A product manager, on the other hand, would take the agile approach, splitting the development process into sprints and focusing on delivering a minimum viable product (MVP) quickly, in order to compare the results with the actual market need and be able to implement changes. 5 components of a product mindset Vendors with the product mindset are in the habit of constantly brainstorming new ideas in search of better ways to achieving their goals. Being creative, they tend to focus on the outcome rather than the process. This approach provides them with a better understanding of how to get things done in a lean way. Here are the core dos and don’ts of a vendor who thinks product. Deliver value, not features A product-centered approach doesn’t welcome adding a feature just for the sake of it. The vendor’s main task is to think of benefits to the customer from using the product. If a product helps handle real problems, customers could return for product updates. Therefore, vendors communicate with the target audience via an MVP and marketing channels, understanding practical customer needs, gathering feedback and amending the product to make it solve acute problems better. Don’t try to get everything right Vendors shouldn’t expect to get a flawless product on the first try. Developing an MVP to test the idea might help determine the target audience and let users test the product. Early adopters could pitch a new feature and provide a concept, and the vendor would need to gather feedback to decide if the idea is worthwhile. User feedback Product creators build initial promotion campaigns to engage more users and entice them to leave feedback or take other action, as planned. Valuable product features and chosen marketing communication methods will determine the number of early adopters and followers. A product-focused vendor will find out the audience’s expectations, identify the pain points of the product and work out methods of solving them. Stay flexible Sudden changes in the market and shifting audience preferences shouldn’t frustrate a product vendor. When a trend, product or competitor changes, a vendor should know how to change tack and adapt the product. An agile approach will help embrace changes smoothly and allow the vendor to come up with new features for the product. They might have to modify their company culture to become agile and adopt the product mindset. Stay consistent Reliable vendors shouldn’t stop delivering value to their clients. They evolve their products, monitor changes and test new ideas of exchanging value with clients and end users. There’s always room to make a change and improve the offer. When a vendor delivers a great product or service, the audience will appreciate it. Check if your product outsourcing vendor has the product mindset You may be wondering how exactly to find out if a potential vendor of outsourcing product development services has a product mindset. The best indication is the questions the vendor asks and the topics they raise. If you can evaluate these questions and their reasons for asking, you would get a good sense of whether the vendor’s priorities are product value and client success, or project plans and limitations. The following are dead giveaways for the product mindset: Vendor enquires about the ways a product could solve real-world user needs. They are interested in the market fit of the product. They try to find out details of the product’s value to prospective users and its potential in the market. Managers might suggest an approach that requires less effort and resources and reduces the number of hours billed. A vendor does a lot of work during the pre-sales phase to understand real customer needs. Digging below the surface of the initial requirements may demonstrate the vendor’s commitment to making the product a success. Vendor’s specialists can comprehend the current status of the product (for instance, problem validation, solution validation, market validation, scale-up) and suggest the best

Code review is considered to be the #1 practice a company can use to improve code quality. But its benefits extend far beyond that, while its drawbacks can be managed by following best practices guidelines, all of which we are about to explore here. Are code reviews challenging? Reviewing code is not that easy, it can be a pain in the butt actually. Most of the time you find yourself busy and enthralled in your tasks and then you have to stop and switch context. The cost of interruption, for a developer, is on average higher than 23 minutes so you have to plan your code reviews with intention and attention. The context switching brings in the need for greater memory allocation and that becomes taxing on overall energy and productivity. Code reviews can become a chore and that’s when you need to frame your mind, remind yourself why you’re doing this and what the benefits are, and also use all the tools in your arsenal. And by tools I mean linters and code formatters that can take away from the load of code reviewing. Another challenge of the practice is that it can affect interpersonal team dynamics, few people find pleasure in their code being critiqued and nitpicked and it can also result in people attacking each other. For this, it’s best to cultivate a culture of code review and understand that delivering feedback in a respectful and palatable manner is a celebrated skill. To reduce sensibility to critique, you should stay open to being challenged. This maintains agility, freshness, and the openness necessary to learn and grow. It’s an honor when someone is willing to review your code. And if your sensibility to critique can’t be tamed that means it’s time to become a better developer. When everyone in the team does code reviews and sees their importance and role, the adoption of the practice will prevail. I believe that as time passes by and the team matures, code reviews should end up taking less and less time. The standards and expectations should be more obvious to everybody, the code base more familiar and the teammates should have learned from one another. Psychologically speaking, code reviews tap into what turns out to be a useful human trait, the predisposition of seeing someone else’s mistakes a lot easier. This principle is prevalent in human life. Why not harness it in software development also? Also when you work on a task, you have the tendency to focus your attention on the problem at hand and therefore put your mind into the box of the task. Sometimes it takes another set of eyes to see outside that box. What’s the point of code reviews anyway? The most imperative reason is that life is short, you do not want to spend your life trying to understand badly written code, you want to hear music when you read code, not a metal pot falling down the stairs. Code reviews are your first chance to raise code quality, to make sure you don’t end up working on a mess of a code base. Use this chance! Code reviews are a critical part of the development flow. It’s one of the best ways to accumulate knowledge. The best way to learn how to code is by reading code and understanding it. As a new member of a team, as a junior, reviewing code it’s your road to success. Usually, the more senior members of the team are busy and after a lot of years on the ‘battlefield,’ their patience might be limited. Use code reviews to learn the project, the style of work, standards and to avoid asking questions that you can answer yourself by looking at the code. Thus you become more resourceful, a necessary skill for a developer. Increase the ‘bus factor’. You don’t want only one of your team members having too much knowledge. If that team member got hit by the proverbial bus then no one on the team would know anything about the code. Code review is the opportunity to take ownership of a larger part of the codebase and ensure you have a general view of how things work and are connected to each other. Code reviews contribute to earlier detection of issues and prevention. This ensures that the development will be underway on a stable code base which is then reflected in the speed and correctness of the implementation. The overall health of the codebase does not diminish over time. Having a main reviewer can save a lot of issues down the line. Somebody who reviews code from every part of the app will be able to foresee any major sources of bugs, problems in the design, detect missing functionality, see any necessary refactoring, reduce code duplication, enforce standards. Being subjected to code reviews might just be the thing that pushes you to become a better developer. Feel the burn, feel the peer pressure! Work those muscles! What defines a good code review A good code review starts with the author of the code Your intention should be to make it quick and easy for others to understand the code you just wrote and decrease the wait time for your code to be reviewed and merged. The first rule you need to follow is to keep your PRs (pull requests)/review requests as small and as cohesive as possible, one issue – one pull request. If your task requires many changes in many files, see if you can create multiple smaller PRs. Provide descriptive titles, comments. Avoid commit comments like ‘changes’, ‘code adjustments’, ‘small edits’ when possible. Having multiple descriptive commits, one for every issue you’ve tackled on accomplishing a task, can actually be a learning opportunity to others, by providing more context of what happened during the development and what changes were necessary for every issue. Don’t forget about adding comments in the code when needed or encapsulating code in functions with descriptive names. Usually, comments are also necessary when you do something a bit more unusual than

As a .NET Technologies Department Lead at Nordlogic, I am always preoccupied with the functional and dynamic aspects of teams, and I try to learn as much as possible through reading books and articles. There are many approaches to how a team should be built, each relying on a different underlying theory. One of the most interesting ones is described by Patrick Lencioni in his book “The Five Disfunctions of a Team”. The five dysfunctions of a team model is considered by many as one of the best setups to build teams. What makes it so appreciated and adopted is the simplicity of the principles, their flexibility and the fact that it doesn’t exclude applying other systems or techniques. The book starts with a fable where Kathryn, freshly appointed CEO of the fictional DecisionTech, faces challenges in the leadership team that could make or break the company. This is meant as a way to ease the reader into the model and give lifelike situations on what could happen or what are the pitfalls of applying the system and redefining the team. A pyramid, depicted below, is used to display the dysfunctions, because the author sees them as deriving one from another, one layer to the next, with the “absence of trust” at the base. Addressing each potential dysfunction provides the steps one needs to take in order to build a highly functional team. Trust is the foundation of a functioning team. Trust is the foundation of a functioning team. In Leoncini’s view, teammates must be comfortable being vulnerable with one another and be confident that those vulnerabilities like weaknesses, interpersonal shortcomings, mistakes, requests for help won’t be used against them. The idea is that once team members are open they can centre their attention on doing the job rather than being political and focus their attention on managing their interactions. One particular exercise the author suggested to aid in improving trust is Team Effectiveness Exercise, where each team member identifies one most important contribution of each colleague and one thing they must improve or eliminate to improve the team. The aim of the productive conflict is to produce a positive and productive idea in a certain amount of time. Once trust is established within the team, conflict is made possible because team members are no longer avoiding debating about ideas.To clarify, conflict is limited to concepts and ideas and personal attacks and malicious comments are not tolerated. The aim of the productive conflict is to produce a positive and productive idea in a certain amount of time. Most teams avoid conflict in order to keep a sense of harmony and avoid hurting personal feelings, when actually doing this may fester resentment and in the long run waste time finding solutions. One technique I’ve found interesting in this section of the book is called Mining, when somebody tries to extract buried disagreements in order to work on them. Conflict enables teams to commit without perfect information. On the next item, the author identifies desire for consensus and the need for certainty as the two main sources of lack of commitment. In great teams, members generally accept that they don’t need their idea adopted in order to get to consensus, but they do want to have their opinion heard and weighed. Not all scenarios and situations permit a full view of the situation, but it’s important to make a decision with the available information and then boldly change course when more information is available. Conflict enables teams to commit without perfect information. One of the recommended techniques is Cascading Messages, when at the end of the meeting key decisions are reviewed, it’s decided what information is relayed to further parties and ensures all colleagues have the same understanding of the decisions. Everybody can be held accountable by their colleagues for behaviours and performance that may hurt the team. Once the team has committed and there is a measure of what’s expected, accountability in the context of teamwork will mean everybody can be held accountable by their colleagues for behaviours and performance that may hurt the team. Far from the common belief, as being a source of damaging work relationships, Leoncini sees this process as a way to avoid deterioration of morale and to decrease resentment. I think this is a sensitive area and a problem even in more mature teams. Especially in cultures where this process can be perceived as criticising others, establishing clear team rules is needed. Steps like Publication of Goals and Standards, Simple and Regular Progress Reviews are self explanatory and will help to make team members accountable. A lot of teams are not focused on the results. The final main dysfunction of a team is the inattention to results. Every team defines what it wants to achieve in a certain period of time and these goals make up the desired results. A lot of teams are not focused on the results, meaning they actually lack the desire to succeed. Two of the things that can stay in the way of success are putting too much emphasis on the Team Status or Individual Status.* Team Status* means that people are content with being part of the team and, while certain objectives might be beneficial, they are not worth for them to change the status quo. Any team can be affected, but especially political organisations, well established companies are prone to have this dysfunction. Individual Status means that individual people from within the team put their careers and positions on a much higher level than the actual team. As for things that can help teams to commit to their goals, Public Declaration of Results is one of the ways for teams to commit to their goals. They publicly declare what they want to accomplish and this public acknowledgement should give them the motivation to strive to achieve them. The importance of the leader The importance of the leader or a leading figure within the team is stressed by Leoncini. By example, he/she can apply a concept first in order to encourage the team members. On the trust

We all know that every successful software product starts with a big idea. However, it takes a lot of time, energy and dedication to take that great idea and transform it into a successful product. Most importantly, you need the right technology and architecture to ensure a seamless experience for your end-users. Unfortunately, in many cases you don’t have the necessary resources to take care of both. But there is a simple solution for this: Information Technology Outsourcing (ITO). To outsource or not your software development services to Romania? There are many reasons to consider software outsourcing to Romania, otherwise this country would not rank high among the most attractive destinations in the world. Over the past decade, Romania has entered the radar of many tech global companies thanks to its logistical advantages, multilingual highly-skilled workforce, time zones compatibility, and competitive outsourcing rates. The Romanian IT landscape is very dynamic and has all the makings for an attractive outsourcing destination. According to the annual report of the Romanian Business Service Leaders’ Association (ABSL), Romania’s outsourcing sector currently employs 1.5% of the country’s population and generates 4 billion Eur in yearly revenue. Choose your software development team from a large talent pool What are the main drivers fueling the growth of the Romanian IT workforce? First of all, students are encouraged from a very young age to pursue a career in information technology, computer science, robotics, and other related fields. Eastern Europe has a long history of outstanding technical and math schools. Another important factor to consider is the government measure exempting software professionals employed by Romanian IT companies from paying the 16% income tax. Both the education and the legal systems are supporting the fast development of the Romanian IT landscape. These incentives are really effective and, based on research published by HackerRank, Romania is one of the top 20 countries with the best software developers in the world. There are many experts in a wide range of technology skills which explains how Romania ranks first in Europe and sixth in the world for the number of certified IT specialists. The most sought-after skills are in web technologies (JavaScript, Angular, Node.js), mobile technologies (Xamarin, Ionic, NativeScript), cloud technologies (Azure, Google Cloud, AWS), embedded development and IoT, as well as DevOps. Easy access and time zones compatibility with Europe and the USA Geographical position and easy access to the country is very important and, once again, Romania wins this round in the global outsourcing game. Although we are keen on remote collaboration, sometimes it’s nice to meet our foreign clients in-person, and share with them the traditional Romanian culinary experience and also the infamous “palinca”. Fortunately for us, we are ideally situated on the continent, only one or two-hour flight from any important European destination. And ever since we joined the European Union (EU) back in 2007, traveling to Romania from another EU member state does not require a visa. Being part of the EU also means that Romania’s legislation is matching the EU standards, including those for copyright laws and IP protection. Another advantage is the fact that Romania’s broadband internet ranks fourth in the world in terms of average download speed. Additionally, the location in the GMT+2 time zone allows for real-time collaboration with any European country, and for 2-3 hours overlap with the United States, thus truly making Romania an ideal software development partner. Easy access, real-time communication, and fast internet – three of the main reasons that make Romania such an attractive ITO destination. Cultural fit and excellent foreign languages skills We appreciate that speaking the same technology language is important, but it is not the only factor that can determine the success or the failure in software development outsourcing. Often overlooked, we think that a key ingredient in ensuring a good international collaboration is the cultural compatibility. We are talking here about sharing similar values and lifestyles, which makes Romania an ideal cultural fit for Western European countries and the United States. If there is another thing that Romanians are well known for, it is the ability to learn and speak foreign languages. We know from experience that for any IT specialist English is like a second mother tongue. Other language skills include French, German, Spanish, Italian and Hungarian. Closing notes As you can see, in Romania you will find a highly-skilled and competent polyglot workforce, with a strong European mindset, committed to your software development projects, and maintaining close business relationships. To sweeten the deal even more, there is a perfect balance between cost and quality because of the entire industry’s focus on delivering quality at competitive prices. We can continue writing about the many reasons why you should develop your software product in Romania, or we can schedule a short call and discuss directly on your current software development needs. Because here at Nordlogic, your ideas become our mission. Our passion for technology and innovation drives us to deliver cutting edge solutions to delight your customers and exceed their expectations. Article by Nordlogic

You’re coming home after a hard day at work.  You throw your bag on the couch and grab the two slices of cold pizza left over since last night (you hope), barely feeling the taste of it. With the last bit of energy you throw the box on top of the pile of other boxes from food delivery you have lying around in your room, next to the pile of dirty clothes. It used to be a nice room and you were proud of it, decorated it yourself, and you had friends over for a beer, but now, you’d not invite their dogs over. You promise yourself you’ll clean all that in the morning, and fall asleep. You wake up scared by your phone ringing, and you barely get the cochance to get a quick shower before you storm out towards the office. Another crisis needs to be taken care of. Your room can wait. Maybe next week-end. If all goes well. Sounds funny? It is, unless you’ve actually been in that spot, in which case it’s actually sad. The good news, though,  is that the solution is already there: take time to clean the mess. Over the course of the past 25 years, I’ve seen quite a few software products / projects that resembled the room described earlier. They were masterpieces of engineering when the development started, and ended up like a pile of dirt. As a fun fact, the Software Engineering community came up with a nice name for that. It’s called Technical Debt. Now, I’m not sure about you, but I’d definitely not leave a Legacy like that to my kids. They would put me in the worst retirement house when the time comes. Sometimes, the Technical Debt affects even pretty recent projects, say 2-3 years old, top. I’ve seen Technical Debt  being present even in projects built over the course of just a few months. How did that happen? Why did that happen? What exactly is this Technical Debt? Every time you skip a good practice (sometimes as simple as taking a food box to the trash after you’re done eating), you end up with a mess. And then, the mess will pile up, till the amount of mess you deal with is unmanageable. And it’s called a debt because you owe it to yourself, to clean it. Mainly to the future you. Who will otherwise hate you. When it comes to Technical Debt, this is accumulated when the team skips the good quality practices specific to the development process: using the right architecture, writing the code with the right patterns & principles in mind (ex. SOLID Principles) and following good practices such as Test Driven Development, Peer Programming, Code Reviews, Continuous Integration, etc. Why does Technical Debt happen? There are many many reasons why a software product or project degrades over time and becomes really hard to maintain.  You can consider a product as being a pyramid. The tip is the actual product and the base has 3 sides: people, technology and processes (practices). If you maintain a good balance on all 3 sides, the product can grow nicely and maintain that balance. If you ignore one, or push too much on another, the product will eventually fall. And fail. When it comes to people, it’s clear that the lack of skills or motivation is quickly going to lead to technical debt. Lack of proper processes and practices, specific to all areas of the product (DevOps, development, quality assurance, management, etc), or too much process, can also put the product on its head. With technology, things are no different. Not enough investment and focus on technology (choosing and using the right tools and technology, not understanding it properly due to lack of training, etc) or too much emphasis on it and usage without a proper risk analysis and due diligence can lead to a catastrophic end of the product, making it unmanageable. How can we know if we’re affected by Technical Debt or not?  What is the impact of the Technical Debt? Technical Debt manifests in different ways, depending on the product type and stage of development. Usually, the following signs suggest that Technical Debt is piling  up and needs attention: Increasing number of defects Performance degradation Security problems Reduced team velocity / performance Low team morale, satisfaction and overall productivity Inability to adopt new technologies or upgrade existing ones Inaccurate estimations and delayed delivery Long turn-over time for new features and even for bug fixing Lack of tests, outdated tests or tests failing consistently Frequent updates of the same classes / modules in your source code repository How can we avoid letting our products to head the wrong way and accumulate Technical Debt? The answer is simple: prevent the mess as much as you can, but when you can’t (for a while), make sure you address it as early as possible. Ideally, you and your team should have the practice of continuously preventing and addressing technical debt. Agile/ Scrum teams use the concept of Definition Of Done which is extremely valuable in ensuring that all quality criteria are met before a unit of work is considered completed, and ensuring that they are well understood by all team members. Some of the standard Definition Of Done criteria you should be focusing on are: Unit tests have been built or adjusted accordingly (and you might want to also target a specific Unit Test coverage threshold). And of course, they need to pass. Integration tests have been built or adjusted accordingly (depending on the type of the product / project, you should also consider security tests and performance tests to be part of the Definition Of Done). Again, having them run automatically and also passing, is a must. Code has been reviewed both manually, using Code Review practices, and automatically (using tools for code style checking, secure coding validation, static code analysis, etc.). Ideally, you would have all these automated code reviews performed on every check in or pull request into your source code repository (ex. git). Documentation has

So you are the person in charge of a software project. It may be something small, an MVP (Minimum Viable Product) or a large enterprise project. You want it quickly, cheap, and without bugs. I’m not even going to say the “pick two” cliche (there, I said it), but the truth is that too often in the industry, not even two of those boxes are being ticked. There are many variables affecting the quality of the delivered product. Testing, which is my focus here, is one of the important ones. How much effort should be spent on testing? There is no silver bullet answer. How much effort should be spent on testing by the project team? While more testing is usually better than less, it comes with a cost. While the cost increase is roughly linear with the increase in effort, the benefit curve will flatten at some point: more testing, while continuing to add to costs, will not bring any significant increase in quality. There isn’t a silver bullet answer that matches every project, and the right answer has to take into account both costs and risks. When thinking “risk”, two main components have to be taken into account: What is the probability for an undesired event to happen? What are the consequences of such an event taking place? The right answer will always depend on multiple factors such as: Business maturity – early startup, mature startup, enterprise, etc. Industry – financial or health care will have a different risk profile compared to NGOs Project type – more risk is acceptable for an application developed for in-house use compared to an app that will be used by external customers The two ends of the spectrum are: A. Startups Startups often need to spend a lot of their early efforts validating their business idea with real users. Given the high quality expectations users have in today’s technology ecosystem, releasing a buggy app just for validation purposes is not a good option. It may be a better idea that early validation is done using a clickable mockup solution instead of implementing the functionality in an app. This is fast to create, as there are quite a few viable solutions on the market (e.g. InVision, Framer, Marvel, Origami, Moqups, etc.), and requires almost no testing at all. The next step would be to implement an MVP based on the feedback received during the previous phase. While testing is needed in this phase, cost can be kept under control by focusing on developing only features that have been identified as relevant/important to early adopters. Once past the MVP stage, testing needs to become an integral part of the development process. B. Enterprises Both expectations and stakes (financial and reputational) are usually high for enterprise level projects. Corners cannot be cut, and applications need to be tested to the extremes for full compliance with both functional (what the application should do) and non functional (security, performance, scalability, etc.) requirements. This should always be done, and is usually possible as enterprise budgets are more generous than startup ones. The QA team need to work closely with the business in order to develop and maintain a test plan based on relevant use cases. At times, clients may be tempted to reduce costs by doing the testing themselves. It doesn’t work. At times, clients may be tempted to reduce costs by doing the testing themselves. It doesn’t work. Even without realizing, they are not ready to receive untested functionality, and no matter how many times the development team will reiterate that the functionality has not been tested, the client will be left with a feeling that what they received was of poor quality. You need to let the team test their work before they deliver it to you. It’s a product, let the team developing it finish it properly before you receive it, and it’s not really finished until it’s been properly tested and any issues found during testing were fixed. Would you ask the maker of your car to skip quality control for a reduction in price? When you buy a car, you don’t ask the maker to skip quality control for a reduction in price. Testing should not be thought of as being separate from development. It should be part of the development process at (almost) every step, and coding itself should be done with testing in mind. The way an application is written should facilitate testing as early as possible, with Test Driven Development being a very good example. To summarize, how much testing you need will depend on your particular project, but you do need testing! You should discuss it before project start with the development team, and it should depend a lot on priorities and on the amount of risk you can afford to take. It is important that you communicate from the very start all the specifics and agree on a plan that will maximize the chances of project success. Article by Andrei Olariu Chief Executive Officer