Technology tools and frameworks are rapidly advancing innovation. Software development is currently essential for any competitive business, which is why, for all CxOs, adopting a strategic approach to building and scaling digital products is vital.

If you’re a C-level professional, buckle up to explore software development topics like:

• system scalability,
• the development of new features,
• effective management of technical debt,
• system observability,
• alignment of business goals with project requirements,
• and the critical task of finding and retaining tech talent.

We’re here to unpack the tech puzzles and arm you with savvy solutions to 5 common software development challenges we’ve often seen ourselves.

Why talk about this?

Well, at SoftwareMill, we aim to be a reliable technology partner. Our team works on diverse projects daily, encountering both good IT projects practices and challenges. By sharing insights into common issues in software projects, we might offer some helpful perspectives for your own digital product, contributing to an overall improvement in the quality of software solutions. And make our brand better known in the world! ;)

In an ideal scenario, your software product would have the perfect IT infrastructure, cost-effective, and ready to serve both existing and future clients. However, the reality is different, and change is a constant in software projects. Every process of delivering software is hard for many reasons. It’s usually difficult to:

• anticipate all the situations a software program will be faced with,
• manage the complexity of system development in the context of changing requirements,
• plan and continuously execute development plans well,
• compete in the industry without introducing some new ways of doing things.

Very few companies have no issues during the development process. Many struggle to:

• build software on optimal technologies in an ever-changing environment and manage technical debt efficiently,
• motivate the delivery team and create honest feedback culture among developers and business,
• establish development processes oriented toward quality,
• coordinate and communicate effectively.

We believe that exploring our list will help you prioritize the continual generation of enhancements and the delivery of high-quality products as fundamental elements in scaling your software like a tech native.

1st problem: scalability

To meet changing demands of a business, you need to be ready to scale. If this is not the case now, it might become your challenge in the future. That is not to say that you should make significant investments upfront into e.g. sophisticated auto-scaling or an overly flexible architecture. However, you should avoid the opposite, and design the system in a way which at least permits scaling. This does need some upfront design. But, this will be an enabler for teams tasked with adjusting the system to cope with higher demand, if such a need arises.

To manage challenges connected with growth, you need skilled software engineers with a good understanding of, e.g., performance patterns, real-time data processing, and software architecture growth-related issues.

First of all, how do you even know whether your company has a scaling problem? During the peak workloads, such as Black Friday, users may complain about user experience, or the project may become unavailable. If architecture is ineffective, you may also see huge costs increase.

If your system is not scaling, you need to investigate various potential sources of a problem. Let’s take a look at this from the software architecture perspective. Unfortunately, there is no such thing as “magic scaling sauce” (a term by Martin Kleppman). There might be problems in many elements of the system, and usually, it is a mixture of many issues that need to be fixed. Maybe your database doesn’t support scaling, or your data model is wrong. How to uncover that?

Start with the planning and dig deep

Clients who approach us often deal with scalability issues. In order to investigate what’s wrong, we usually follow these steps:

1. We start by conducting an in-depth examination of the client’s product and its software architecture. During our collaborative workshop or series of meeting sessions, we actively engage with the client, asking questions needed to grasp their requirements comprehensively.
2. We make sure to really understand which business flow, or use case is problematic, because usually it’s just a small part of the whole system and processes.
3. Subsequently, we discuss the challenge internally. We focus on making a rescue plan for this particular issue and the biggest problem in the whole system architecture. This collaborative brainstorming ends in formulating a detailed plan listing the necessary steps for system analysis. These steps may include:

• Setting up a dedicated environment: establishing an environment exclusively for performance tests and accurate evaluation.
• Creating performance test scenarios: using tools such as Gatling, we craft test scenarios that comprehensively cover distinct segments of the system. This approach is essential for identifying the throughput of each flow component and the potential bottlenecks.
• Microservice profiling session: if the problem lies inside some specific microservice, a profiling session becomes useful. This deep-dive allows us to meticulously analyze and address challenges within that particular component.
• Once our plan is refined, we present it, along with our findings, to the client. Our objective is to ensure alignment between the proposed project scope and the client’s budget and timeframe. This collaborative and transparent approach ensures that our strategies are not only effective but also feasible within the constraints defined by the client.

Another perspective to take into account when scaling becomes hard is your technical team. Trying to do too much with too few programmers is a common strategy for startups. But as the business naturally grows, the backlog steadily increases, and you need to make that leap into recruitment, or look for external dev talent to help your team.

You might be interested in reading: What happens after you contact us?

2nd problem: adding new features

Navigating the market, driven by the need for swift deliveries and a competitive edge, prompts the continuous enhancement of software. Whether opting for incremental improvements, a complete rebuild, or a hybrid approach, encountering challenges when modifying code brings potential issues that demand attention.

• when speed of delivery becomes a priority. It introduces technical decisions that are made for the immediacy, simplicity, or budget that, while working today, will harm the software in the long run.
• when management does not include any time for technical tasks like cleanups, refactorings or upgrades.
• due to the flow of time: software is in an ever-changing state. Libraries, frameworks, and operating systems evolve and become obsolete. New versions might bring performance, usability, or security improvements, but also mean that every software project needs maintenance not to fall behind too much.

When adding new features becomes hard, your software most likely deals with some form of technical debt. Technical debt may be created in a few situations:

Unlike financial debt, technical debt operates in the shadows, often escaping immediate notice. The peril lies in its silent accumulation, posing a threat that can impact your development pace, dampen team morale, and, in extreme cases, jeopardize your business.

The initial stride in handling technical debt is evaluating its extent. While managing technical debt is a nuanced process with no universal playbook, understanding where it arises provides a crucial starting point. This awareness allows you to identify issues, paving the way for targeted solutions tailored to your specific challenges.

Tech debt in code

As code quality issues pile up, the process of adding and testing new features takes a hit, demanding extra manual effort and exhaustive regression testing from developers. Regardless of the programming paradigm employed in your product, it’s crucial for developers to consider how components connect and adhere to guidelines for crafting maintainable software.

The creation of clean code and adherence to programming best practices play a pivotal role in managing technical debt and unveiling what’s hidden. While low code quality is a clear indicator of technical debt, it’s important to note that the comprehensive scope of technical debt extends beyond what can be calculated solely from the source code.

Let’s look beyond the code.

Tech debt as a result of business decisions

Ensuring the long-term success of your product hinges on effective technical debt management. While some degree of it is inevitable, a proficient development team can adeptly navigate and address it. Intentionally incurring technical debt may speed up time-to-market, but it demands vigilant monitoring and stakeholder accountability on what they want to introduce to the system on purpose and at what costs.

Let’s steer clear of introducing features that might become a headache later. And don’t forget, regularly checking and updating your system isn’t just a good habit — it’s super important to keep everything running smoothly. It’s good to remember that the more code you have, the more, unfortunately, time you have to allocate to maintaining it. It’s not like you can write it once and it will work “forever”.

Tech debt caused by insufficient or out-of-date documentation

In a perfect world, developers document what decisions were taken and why (e.g., using Architecture Decision Records — ADR). In reality, not everything is well documented, and the worst case scenario we’ve been seeing, not that seldom, is that no one working at the company knew anything about the technical side of the project. Yikes.

Tech debt caused by poor technical leadership

Bad technical leadership may prioritize quick fixes and short-term solutions to meet immediate goals without considering the long-term implications. CTO must reconcile business needs with technical needs. Remember the already mentioned growing maintenance cost? A good CTO knows how to reconcile such things well.

In case of bad leadership, there also might be no clear vision for the product, a lack of implementing best software practices, coding standards, and architectural guidelines, a lack of code reviews, and overall bad communication that impacts the whole development team.

All these results in a failure in creating an environment for sustainable and high-quality software development. As a CxO, you should prioritize long-term planning, foster a culture of continuous improvement, and guide the technical team toward decisions that align with the organization’s strategic goals.

You might want to read: The art of making technical decisions

3rd problem: software system management

Understanding your software’s behavior is crucial for ensuring proper functionality and meeting user needs. Software failures happen, and can have severe consequences.

An interesting read: Bad software examples — how much can poor code hurt you?

First and foremost, many people have realised that microservices are not the way to go ;) It is much better to create a modular monolith, sometimes called modulith, than to go into all microservice complexity. While containers and microservices boost development speed and agility, the dynamic nature of these architectures makes identifying current issues a more significant challenge. In the case of microservice-based systems, monitoring, and troubleshooting complexity are further amplified.

The need for observability in software systems has always been paramount, but with the rise of distributed software trends, it has become more critical than ever. What steps should you take when your product faces observability issues?

How to have an eye for your system?

Ensuring the health of your system requires a robust observability framework that analyzes inputs and outputs effectively. To achieve this, your system should generate sample data, and you must establish mechanisms for collecting, analyzing, and visualizing this data.

Design your software, production, pre-production environments, and deployment pipeline with a focus on continuous telemetry records. This facilitates ongoing monitoring and tracking of your system’s behavior.

Consider exploring the OpenTelemetry project, which seamlessly integrates with various commercial and open-source tools. This integration allows your system to gather logs, traces, and metrics. OpenTelemetry then correlates this data in real-time, providing your Cloud engineers and development team with comprehensive, contextual information. This proves invaluable for identifying the root cause of performance issues and understanding the system’s behavior.

It’s important to note that building a business case for observability can be challenging. Despite being a significant investment, the benefits of observability are often intangible and challenging to quantify. However, you may confirm yourself, CxOs appreciate the ability to identify problems before users. This ability distinguishes outstanding software products from good ones and positions you at the forefront of innovation.

Interesting read: Platform Engineering vs. DevOps: which is right for your organisation?

4th problem: matching business goals with project requirements

• Communication hiccups can arise within a team, with programmers using jargon that business doesn’t get or the tech team not tuning in to business needs. Different interpretations of the same concept among various business reps or departments can lead to confusion. Using different terms to describe things only adds to the mix-up.
• Another issue is the absence of future plans. Without a clear vision, staying focused becomes tricky, causing delays and team misalignment. Stakeholders also struggle to grasp the project’s progress.
• Even with plans, deciding on priorities is a challenge. Opting for a smaller, cost-effective feature over an expensive one can be smarter. Assessing feature development cost versus probability helps in making these choices.
• Lastly, when there’s no collaboration and project deadlines are set without the tech team’s input, goals become unrealistic and unattainable. It hurts everybody involved in the software development project.

In the intersection of business and tech, misunderstandings arise when language and terminology differ. Problems emerge when both parties fail to understand the broader context. In our software development experience, we’ve noticed the following challenges in translating business requirements into the right technical solutions.

Is there a solution?

For effective collaboration between the business and tech teams, we rely on event storming. It’s a workshop approach designed to uncover, discuss, and build a shared understanding of a complex business domain. Typically, at the start of software development or when planning the next milestone, we meet with the client. Together, we identify key events and processes in the system, mapping out interactions among stakeholders and components. The workshop’s aim is to pinpoint crucial events and processes, fostering a shared vocabulary and understanding of the system’s workings.

5th problem: finding and retaining tech talent

For any tech-focused business navigating, the tech landscape and choosing the right stack is crucial. Many CxOs recognize their role in managing software products, but without a top notch dev talent, they fail to set a strategic vision and tap its full business value. Losing developers periodically is normal, but if it’s a recurring trend, it signals an issue that needs attention.

• Outdated tech stacks often drive developers away. Imagine your system still running on Java 1.4 with no upgrade plans while Java 21 is already released! watch the video. In such situations, your team members’ skills feel underutilized, working with outdated tools. Developers seek challenges with modern technologies or strong communities for continuous learning and growth.
• Effective tech leadership is crucial. A good tech leader should be technically savvy, aware of the latest trends, and possess strong communication skills. Leadership matters more than tech knowledge — inspiring and motivating the team is key.
• Avoid the nightmare boss persona — unnecessary meetings, tight schedules, and unclear objectives cause job burnout. Foster a collaborative environment. Managers focusing on team development act as the glue that keeps everyone together.

Creating a comfortable work environment for developers doesn’t have a one-size-fits-all recipe, but you can ensure your workplace is an appealing space that nurtures and amplifies their skills. Here’s what my colleagues say about such an environment:

Summary

Creating good software is a never-ending iterative process. When issues arise, the process involves pinpointing the problem, collecting information, and receiving recommended solutions for your project.

While it might sound straightforward, as a non-tech person, you have to rely on tech experts to make this software-building process accessible, clear, and understandable for everyone involved. That’s why building trust and making sure you create a culture where people can review each other’s work often and honestly is important.

Reviewed by: Adam Warski

Stay tuned for a second part when we discuss a more soft-skills approach to delivering software. At the end, behind every great product, there are people and relationships.

Originally published at https://softwaremill.com on October 12, 2023.

Scale your software like a tech native was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Modern software development is characterized by a shift towards cloud-based technologies and a growing desire for distributed development opportunities. As a result, Platform Engineering has emerged as the next cultural evolution in the IT industry following the success of DevOps.

This approach is now recognized as a competitive necessity that can improve developer productivity through hand-picked infrastructure automation tools, enable self-service capabilities, and reduce errors while increasing reliability, much like Site Reliability Engineering (SRE).

While both Platform Engineering and DevOps play crucial roles in successful software development, it’s essential to understand the differences between these two approaches. Doing so lets you make informed decisions for your organization and achieve successful software development outcomes.

What is Platform Engineering: the road to standardize processes and reduce cognitive load

Originally in software development, developers who created the software also ran it. That was a very long time ago. Later, when the distributed approach to building software became more popular, Ops and Dev teams split and worked separately. It was inconvenient and time-consuming, sometimes taking up to six months to move an idea from origin to production. To address this, we created DevOps. DevOps philosophy brought teams back together to reduce the time between making changes to a system and delivering high-quality software on a continuous basis. For a detailed account of this history, check out this informative YT video.

Cooperative building, testing, releasing, monitoring, and maintaining applications eliminated the need for code to move between different specialists. That is why development and operational expertise baked into cross-functional teams significantly improved some software teams. Still, some organizations failed to see desired results due to the vagueness of defining DevOps roles and responsibilities.

Some organizations have shifted operational tasks onto developers as part of their DevOps adoption, which has had mixed results. While senior developers are often capable of managing many of the tasks previously handled by ops teams, this has sometimes resulted in overburdening them with additional work and increased cognitive load, leading to developer toil. Organizations that rely heavily on infrastructure realized that they needed to provide the right level of abstraction and structure to ensure a successful DevOps adoption and operation.

Welcome, Platform Engineer

So, if you’re a developer, don’t worry about trying to know everything about Kubernetes or security or any other DevOps service. Instead, focus on delivering the features that your users need, and let other experts handle the rest. This is how the Platform Engineering concept comes into the picture.

The platform engineer’s role is to build internal developer platforms to improve developer experience and increase developer productivity. Platform teams integrate all operational services in one internal platform that enables continuous delivery while its users, developers, DevOps engineers, and SRE engineers, can operate at their speed and cadence.

What is Internal Developer Platform (IDP)

In the cloud-native era, software engineering is only getting more complex and challenging, so operational excellence has never been so crucial. Engineering software now involves engineering organisations to be agile and autonomous. To help software teams access reliable tools and workflows and manage their applications in production, Platform Engineers create Internal Developer Platforms (IDP). These platforms enable developers to self-serve and operate effectively without needing to understand the entire ecosystem.

Internal Developer Platforms (IDPs) are designed to be user-friendly and adaptable to changing technologies. The Platform Engineering team treats all other teams as customers, meaning that IDPs are only useful when multiple teams require the same services. If only one team needs a particular service, they should build it themselves. The goal of building IDPs is to create golden paths for specialists who build software, which means providing them with well-defined and reliable methods that improve the software delivery experience.

Spotify was the first company that leveraged standard tooling to improve its developer experience and increase DevOps productivity.

TL;DR: Spotify’s Platform Developer Experience (PDX) team created CI/CD tools and automated processes because they found out that using a DevOps model where teams were responsible for their features led to fragmentation and “rumor-driven development.” To eliminate it, PDX created Golden Paths, a set of best practices for various engineering projects to provide an opinionated and supported path to build services. More about it on their blog.

This is an example of a self-service-driven organization where the platform engineering team binds all the other team needs and based on this, builds an internal developer platform that does the operations for developers while the platform engineering team works on making the platform better as requirements change.

Characteristics of a good Internal Developer Platform

• You develop it as a product. It has a product owner to ensure that it serves the needs of its clients (developers) well and in a user-friendly way (intuitive UI, elegant API, and good CLI).
• You use golden paths so your IDP provides standardisation, reusability, and speed for developers.
• You implement security and compliance implicitly.
• You build in observability.
• You build it with scalability in mind so your technology can keep improving in terms of usability and user experience as needs are changing.

Platform engineering teams vs. DevOps teams: differences and similarities

Putting a clear line between these two methodologies can sometimes be challenging. Platform engineering is often implemented after a DevOps initiative is already present. It is not a replacement for DevOps but more like an evolution. There is some overlap between the two approaches, yet the two disciplines focus on systematizing and supporting different stages of software delivery.

To build an effective software development lifecycle (SDLC), consider combining different philosophies and taking the best practices from various disciplines. Integrating DevOps, SRE, Platform Engineering, and other relevant methodologies allows you to create a customized, efficient, and effective process that meets your unique needs.

Every project is different and demands a tailored approach. While constructing an intricate development platform might not be practical for a small startup, relying solely on “pure” DevOps may pose scalability challenges for larger organizations.

Even with a substantial ops team, meeting all developers’ requests might be insufficient. The key lies in empowering developers to become self-sufficient, enabling them to work efficiently.

Ultimately, the goal is to provide developers with a comfortable working environment, allowing them to concentrate on delivering business value. You need to find out how to strike the right balance for your project’s success.

Grzegorz Kocur — Head of DevOps at SoftwareMill

Platform Engineers vs. DevOps engineers vs. SRE

DevOps — short for Development and Operations — is a philosophy. Its implementation may vary from organization to organization. The overall goal of DevOps is to focus on infrastructure that gives dev teams more control over shipping code to production. In their daily work, DevOps engineers boost the speed and quality of software delivery while reducing errors and downtime. If the system is available and users are happy, you can be sure your DevOps team is doing a good job.

After the code is shipped to production, SRE engineers take over and focus on system reliability. SRE is all about keeping services built by software engineers up and running for potential consumers. SRE is fundamentally doing work that has historically been done by an operations team, but using engineers with software expertise. If your system metrics are healthy, SRE engineers are doing a good job.

Finally, Platform Engineering is an evolution of the two previous approaches. The concept is built around the vital needs of software engineering organisations, mainly cloud-native companies. It focuses on enhancing developer productivity by enabling developer self-service. Successful platform teams architect efficient team-to-team interactions that are involved in building distributed systems. Platform developers' work can be also efficiently used by Ops and SRE specialists. The more swiftly and efficiently various developers' teams can work, the better your platform team is.

DevOps or platform engineering or hybrid?

When building modern software, each development team is responsible for developing solutions from beginning to end. For some teams, production means end-user applications running in production. For some teams, it might mean developing internal services consumed by other teams. You can leverage all concepts: DevOps, SRE and Platform Engineering to create efficient, effective, and scalable software development processes.

Every organization has different needs, and your main focus should always be on meaningful collaboration between specialists responsible for your software development lifecycle. Our approach as software consultants is rooted in a deep understanding of technology. By working closely with your team, we can understand your unique challenges and requirements and develop practical solutions that enhance your developer’s productivity and help you achieve your goals.

Originally published at https://softwaremill.com on May 17, 2023.

Platform Engineering vs. DevOps: which is right for your Organization? was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

For companies that create digital tools, bringing more feature-rich and innovative products and services to the market is the goal. From a developer’s perspective, choosing the right technology stack is a factor of success for every software project.

However, the process of designing the right architecture for a digital product, deciding which database will be used or choosing the proper data structure for storing records — all these decisions present many challenges. Getting your tech stack right from the start to facilitate scalability and finding and retaining top IT professionals in your development team are equally important elements of software development and delivery.

Just last year, we helped 20 organisations build efficient, reliable, and scalable products. We know first-hand how important it is to be able to sustain a high pace of delivery over the course of years through building robust IT systems. Today, we share how taking a strategic approach to shaping your tech stack will help you achieve goals with your software project.

Why do you need to choose the right tech stack for your project?

Making technical decisions is the process of choosing technologies, frameworks, programming languages, and other development tools to solve a given problem. These decisions can go a long way in making your life easier or miserable in the future.

The way you build your tech stack has much influence on your company, product, and development team. There’s plenty to consider where technology adoption is concerned. Each technology stack has its advantages and disadvantages, so it’s important to make sure to select the right tools that could help you the most with your project.

There are usually some trade-offs. Nevertheless, your choice of tools will always determine the type of software you can build and the kind of engineers you should hire. The decisions regarding your future tech stack are also going to influence:

• your system’s performance
• how easy it is to scale, e.g. add more users or storage as needed
• time to market
• the ability to add the right skilled people to your development team
• the cost of maintenance of your product
• how users will interact with your application
• how easily you can make changes to your project as it evolves

The elements of a modern tech stack

Tech stacks are the tools developers use to build software products. The basis and the heart of any advanced digital product is its corresponding backend — the server side, and the frontend — the client side. Beside these two basic components, we can distinguish categories like:

• Data storage and querying
• Servers and load balancing
• Monitoring and performance tools
• Analytics tools
• BI tools

Popular tech stacks

There are popular technologies and optimised frameworks that can help improve the performance of applications in terms of data management or can add a lot of ready-made libraries for developers to speed up the process of writing code.

You can get inspiration from popular companies’ tech stacks, but since the number of available development elements is only growing, that basically means there are no two identical tech stacks.

In the end, everything you choose for your project has to fit your specific needs and all of the elements must work well together.

Pairing the right technologies together is one of the most critical decisions because it could make all the difference when it comes to increasing your business’s productivity and success.

By making the right choice, you help your developers accomplish more in less time. Speaking of successful products, let’s see good tech choices in action.

Tech stack behind innovative and resilient software

Businesses that implement innovations based on a specific technology faster leave the competition far behind. Let’s take a look at Uber, one of the fastest-growing companies in Silicon Valley history.

There are many competitors in the taxi industry, but the company has brought a revolution in car services all across the world. Uber’s use case proves that effective personalisation and relevant customer engagement strategies work. Data is very important for Uber. They build scalable streaming pipelines for near-real-time features. Their pipelines are fed with data about all rides, car requests, they even track drivers going through the city without passengers to know the traffic patterns.

On the product front, Uber’s data team is behind all the predictive models powering the ride sharing cab service, making the company the leader in the industry. Uber transforms and scales faster by leveraging the right technology to offer a unique customer experience.

On the Stackshare.io website, you can check the Uber tech stack that the company utilises today. Each stack decision has a link to the original source content and was created based on Uber Tech Blog and Uber communications. See the full tech stack here.

Technologies chosen by Uber to build applications and manage data

Technologies chosen by Uber in the DevOps area

Your tech stack choices and technologies have a big impact on how you scale both your team and your software. It determines your product success, the types of developers needed, and what they will need moving forward.

Designing robust, high-quality, and secure software solutions is complex and requires up-to-date knowledge on changing technologies, frameworks, and tools. It’s crucial for software-driven businesses to make an effort to involve the right individuals who have hands-on experience in implementing different software architectures and design patterns.

Successful software product needs the right team

Growing your development team is also impacted by your technology choices. Good software craftsmanship is the basis for a sustainable and efficient software development process. What’s most important is to get it right from the start, making software development a strategic priority, not an afterthought.

Sometimes it’s hard to find high-end IT skills in your organisation. The rate of IT adoption by companies has far surpassed the rate of availability of IT professionals. Software engineers, responsible both for designing and building your backend that handles the application logic and rules, and the frontend that serves as the interface for the users, might be hard to find at the pace your project requires.

Attracting new tech talent is hard from two perspectives. Firstly, it’s hard to recruit top IT candidates because they are usually passive candidates. There is a possibility that your next hire may already be employed and isn’t necessarily looking for a change. Secondly, staying relatively small allows you to move faster and be more adaptive, so scaling your team needs to be done at the right pace and with the right people.

Managing the inherent complexity of your existing technology, also making sure the composition of your tech stack is flexible and easy to change according to your challenges, expertise, and specific needs in the future depends directly on your development team skills.

Educate and train to make the right technical decisions

Your stack says a lot about your engineering and company culture. Everyone should feel confident in the tools they’re using, and that the parts of the system are robust and reliable.

You can always upgrade developers’ efficiency by allocating a budget to training your team. Fostering a culture where everyone follows well-established practices and has time and resources to dive into the IT community to learn and skill up creates a cohesive team. This is a habit we practice and preach ourselves.

Check our dev talks by Andrzej Ludwikowski and Jacek Kunicki.

Sometimes hiring external IT experts to help your development team get on the right track is also the way to go. The process should start with a careful examination of your business needs and end with a recommendation for the best strategy to successfully achieve your goals.

When looking for an IT consulting partner, be mindful of whether there is an understanding not just of technical objectives, but also of your business goals.

Experiencing the paradox of tech stack choice first-hand?

Technology landscape is hard. There are multiple tools and frameworks to choose from when looking for the right one for your business goals in just about every aspect of software development. With so many tools to tackle digital transformation, how do you know when to choose:

• Server or serverless?
• Java or Scala?
• Kafka or RabbitMQ?
• Cassandra or PostgreSQL?
• K8s or Heroku?
• Microservices or a modular monolith?
• Event sourcing or CRUD?
• And so on…

Choice gives us freedom and flexibility, but also causes what psychologist Barry Schwartz calls “the paradox of choice”. There is a cost associated with making a choice: slower decision making, distress, and post-decision regret.

“In Schwartz’s estimation, choice has made us not freer but more paralyzed, not happier but more dissatisfied.”

When making your own choices, reading case studies about other organisations’ experiences can be a huge help (and big inspiration about what not to do), especially if their business functions and goals are comparable to yours. But social proof will never replace hands-on developers’ experience. IT professionals can properly evaluate functional requirements and evaluate important aspects of possible solutions in such a way that in the end, everyone gains deeper understanding and settles for the most appropriate solution.

Let’s take a real-world example. The CNCF Cloud Native Landscape Project is intended to be a resource map to help businesses and developers navigate the cloud native ecosystem. You can easily filter and sort hundreds of cloud native projects and products and show details about them.

It can be very useful when trying to make sense of state-of-the-art cloud technologies, at the same time, it may sometimes be very confusing in the process of technical decision making for a specific solution.

Starting from the simplest one: “Should we go for a cloud-based applications design or design specifically for the cloud and optimise for the inherent characteristics of the cloud?” And ending at: “Which tool is right for which job?”, as the number of tools in the cloud native landscape has exploded in the past few years.

The Trouble with Cloud-Native Service Landscapes:

👉 Modern, complex, and dynamic environments are difficult to operate

👉 Their applications and services are no longer self-contained

👉 Prone to unpredictable behaviors at the application level#Devops#Cloud#microservices

- Glasnostic (@glasnostic) January 8, 2021

Key elements of technical decision making process

The groundwork is laid if the different pieces making up your application are of high quality. Custom software must always be designed for a specific set of business needs. The goal is to have a good start, and while solving problems and properly managing the technical debt. The decision making process, even for the same problem, can be different, there is no silver bullet.

When making decisions in your software project, it is important to think strategically and have in mind a couple of rules that may be obvious but are easy to forget when dealing with challenging problems.

• If you’re the one to give technical advice, have a long-term vision, use deep technical knowledge and your common sense.
• Understand that what worked for other teams might not be the right solution for your team. Rely on mature technologies that have been battle-tested and have strong communities. Avoid obsolete frameworks and remember that a new fancy technology doesn’t necessarily mean innovation.
• There are critical technical decisions that are more important than others. You will spend more time and need more expertise when deciding on software architecture — the foundation that sustains your project — databases, frameworks, libraries, services, everything that your architecture depends on.
• Once you have made a decision, involve stakeholders. The biggest challenge is making sure your organisation is ready for a chosen technology and you have their back, as well as everyone feels a part of the process.
• There is a possibility of making a bad decision. You need to be ready that failing fast is an option. It’s very costly and time-consuming to replace or revert a proposed solution when it’s already deeply embedded in your process. Gather early feedback. It helps eliminate potential issues, as well as gain acceptance of your technical decision.

Conclusion: technical decision making

If you feel overwhelmed by the cluttered technology landscape, let us help you evolve your existing applications, rescue your software project or build your software architecture the right way.

When it comes to the nuts and bolts of developing robust IT systems, we have the right experience to scale up your software development team, development velocity and your digital product. Don’t just take our word for it.

Originally published at https://softwaremill.com on July 21, 2022.

The art of making the right technical decisions was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

All digital products we love started from an idea. The adrenaline rush after the ideation process is real, sometimes you might even have the urge to jump right away into the software development process. But building a digital product from scratch is an arduous task. And as much as software engineers always need to test their code, similarly, a business idea needs to be tested before becoming a great software product.

Building useful digital products is a combination of being innovative and following tested software development methods. It requires a huge investment of time, money, and resources needed to succeed. To secure a good start, the first step is to verify the value of your future software solution.

In this post, I will not talk about innovative blockchain technologies, although they are present in the background. I will focus on the proven methods in software development projects that help us build great products. This time, let’s dissect a Proof of Concept (PoC) — a development phase that you can leverage at the very beginning of your product development journey.

To make sure you end up with the product you expect, let’s test the idea behind it first. Is the concept important? Yes, but ideas must be validated in real life. This is what a Proof of Concept aims to do. PoC projects also allow you to dig deeper and avoid potential obstacles when your software will be developed.

What is the PoC definition?

Proof of Concept is a method of validating assumptions with target users and checking if your idea is feasible technically. It involves developing a minimal working state of your final product.

It is especially useful in domains like blockchain or machine learning. Both of these areas are innovative and very costly. They often require project managers to go beyond exploring well-known wireframes or models. These projects are risky for stakeholders not only because they are based on the new high-end technologies, but also because there is usually an outside tech partner involved. And for each business, choosing an experienced tech partner at every development stage, including the Proof of Concept, is crucial.

During the Proof of Concept stage, private blockchain domain experts can work with you and navigate you through the process of finalizing the example idea, checking the needed requirements and adding the functionalities that may be incomplete.

During the Proof of Concept phase, you will answer questions like:

• Is your idea feasible?
• Is blockchain technology relevant for your needs?
• What technology stack should you use?

You will not answer these questions during the Proof of Concept phase:

• Is there a market demand for the idea?
• What do you need to build your product?
• What is the best production process for your project?

What should be included in Proof of Concept?

When starting a process for a Proof of Concept, you should bear in mind a few things that will facilitate the process of validating your initial idea in a given use case. These are:

• the type of information (data) included in the process — to identify blockchain advantages over ordinary security methods,
• process participants — to identify mutual credibility of contractors on an equal level.

The PoC can reveal any potential roadblocks and will give you the answer if private blockchain is worth your time and money.

Proof of Concept vs prototype

While the PoC offers you a model of just one product’s aspect, a prototype is a working interactive model of several aspects of the product. By building a prototype, you will also test the product’s usability and functionality.

A prototype may be completely different from the final product, but the prototype shows how your concept idea works. Prototypes aren’t ready to be released to the market. They are built so that potential clients or investors can test them and give you valuable feedback. You can learn from real-life testing and identify the assumptions needed to develop the idea further.

Proof of Concept vs Minimum Viable Product (MVP)

With an MVP, you will go a step further than when building a prototype. A minimum viable product (MVP) is a version of a product with just enough features to be delivered to the market right away. It’s thoroughly tested and free of bugs, has a feel of a production-ready product.

MVP aims to release as quickly as possible a product with the smallest number of features and some basic design so your target audience can provide feedback needed for future product development success. An undisputed benefit of creating an MVP is that you get feedback from a much larger audience, your early users.

Why do you need Proof of Concept in the blockchain development process?

According to Deloitte’s annual survey, 77% of executives agree they will lose their competitive advantage if they don’t adopt blockchain. But instead of asking “Will it work for us?”, they ask: “How will it work for us?”.

Blockchain is among the most disruptive forces of the past decade and blockchain-based projects in the FinTech world are already well-known. The hype about blockchain is over. Businesses understand the need to be rigorous enough in defining the problems they are attempting to solve with it.

There are more areas where Distributed Ledger Technologies have or can have an impact. This is especially the case when building a private blockchain network to ensure transparency for groups of business partners that do not fully trust each other.

A good read for you: Private blockchain benefits explained

If you see value in enterprise blockchain in your organisation, starting with a Proof of Concept can really help you test the idea and validate blockchain business model potential success before starting a costly software development process.

It is usually a mistake to rush headlong into blockchain innovation without testing out single-use applications. Many enterprise companies are using Hyperledger Fabric as the backbone of their projects ( see some use cases), but usually the first step is creating a blockchain Proof of Concept application for every new project. Blockchain technology is complex and each project shall strive to seek clarity and a well defined technical roadmap before the start.

Risk mitigation

A PoC proves the idea’s viability. It helps you verify core elements of your potential blockchain project and ensure it goes into the right direction, without investing too much time and resources. Starting small with a Proof of Concept saves you time and money.

You can test the solution by building an interactive working model of your concept and mitigate business risks of your business proposal, before showing it to decision makers.

Cost savings

Developing a PoC is worth pursuing when you need to be crystal clear that your potential investors will like your finished product. The PoC process increases the value of the concept so the investor has a clear picture and is confident not to invest his funds in an unrealistic idea.

What’s more, a PoC allows you to reduce future costs as potential traps or technical problems are identified and can be easily avoided in real life. You can generate immediate insights and pivot based on them.

Understanding of private blockchain

With a Proof of Concept, you get a solid understanding of private blockchain technology’s pros and cons in your specific business case, before making a decision about a pilot project. By talking with domain experts, you can not only solidify defined criteria of your concept, but also explore possibilities and list precise requirements for new features.

If your idea turns out to be feasible, a gained knowledge makes it easier to communicate blockchain technology concepts to its potential users or a focus group who will be the beneficiaries of the proposed product in the making.

Project managers can evaluate a tech partner

Blockchain projects are difficult. In-house teams may not have software developers with sufficient experience in private blockchain needed to complete the project. Project managers’ biggest challenge is hiring and retaining experienced software engineers. By outsourcing software professionals, they get immediate access to highly skilled developers.

Choosing a tech partner is crucial for your project’s success. By running a Proof of Concept, you have the opportunity to evaluate the blockchain software development team even before investing into a long and hopefully profitable relationship.

Build your private blockchain Proof of Concept project

Why do you need one?

How can a Proof of Concept determine the feasibility of a real world solution and aid you in verifying your idea? A few reasons why the PoC is one of the most important early stages of implementing a private blockchain-based solution:

• first of all, the evaluation component of a Proof of Concept verifies your blockchain product idea,
• you save time by identifying pain points and potential technical issues in a process that is not time consuming,
• developing an enterprise-ready blockchain requires a lot of knowledge that cannot be easily acquired.

We’re blockchain developers and enthusiasts, happy to help you figure out if blockchain is a good idea for your digital product. Our engineers are hands-on with various DLT technologies: Hyperledger Fabric, Ethereum, Bitcoin, Solidity, and smart contracts design, and have a portfolio of successfully delivered projects.

What does building a Hyperledger Fabric Blockchain Proof of Concept look like?

We offer a time-boxed, 4-week process where we give a space to design the exact flow of the future process, avoiding possible failure and addressing pain points.

We start off right away with strategic workshops and smoothly move on to the development of the Proof of Concept of a Hyperledger Fabric blockchain-based solution .

Proof of Concept Week 1

First, we meet with you at a workshop. The aim of this meeting is to determine the scope of the Proof of Concept and create acceptance test scenarios to verify that the Proof of Concept goals are met.

This is the conceptual part when we get to know your business needs, discuss the specific conditions of your industry, and predict potential problems that are present in your business environment.

After the workshop, we choose one process significant from your business perspective and work with this example to validate private blockchain’s feasibility of your concept.

Proof of Concept Week 2

We verify the feasibility of private blockchain in your industry by analyzing the circumstances specific for your business and your niche. We identify a process to analyze how stakeholders share and manage data and determine if blockchain will really work as an improvement.

Here we prepare initial chaincodes and acceptance tests and we demo the work in progress. We not only discuss and analyze a given case in theory, but we also start coding the solution.

Proof of Concept Week 3

We implement smart contracts to meet your business requirements and conduct a demo in the cloud infrastructure. We consult the idea with you and after your feedback, we test possible scenarios and implement amendments.

This part is important because we show you a working part of the source code that our team members developed to create a simple, functioning architecture based on the Hyperledger framework. At each stage, we want to stress gathering as much feedback from you as possible.

Proof of Concept Week 4

You receive access to the developed source code and guidance on how to deploy the network in your local infrastructure. This implementation is based on one process essential for your business, the selected data will be saved on the blockchain and can be verified by all users of the process.

And that’s it — the process is so quick because we use tools and solutions that we created based on the analysis of the most common problems that private blockchain solves.

In four weeks, you will know if blockchain-based solutions fit your business needs. If yes, we can further develop your blockchain solution to give it more features and expand it to fit your objectives.

Additional features we can implement after the Proof of Concept phase may include: managing permissions to the information and features, a backend application with advanced business logic outside the blockchain, integration with other systems, managing files/documents, automatic scheduled actions, managing users, GDPR compliance, production-ready deployment of blockchain network (distributed among multiple organizations), automatic notifications, custom user interface.

We leave business development to you, let us take care of your software development success:

• backend and frontend development,
• big data & analytics software,
• and/or machine learning Proof of Concept and software development.

Want to find out more? Feel free to contact us and our blockchain team will answer all your questions about your proof of concept and private blockchain software.

Originally published at https://softwaremill.com on November 4, 2021.

What is Proof of Concept in blockchain software development? was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The unique capabilities of private blockchain can solve problems of limited trust between collaborating organizations when other technologies have failed. Blockchain’s core characteristics include a higher level of security, immutability, and automation. Any industry can customize a blockchain framework and leverage a blockchain-enabled system to ensure transparency and build trust.

The most suitable business case of private blockchain is to share the state and business logic among many parties that do not trust each other. Global Fintech players like City, JP Morgan, and HSBC already deployed their private blockchains. But how about other industries? Let’s explore private blockchain use cases beyond FinTech.

Supply chain

For the past decade, the supply chain has become more global, and after 2020, even more diversified. Now more than ever, it faces challenges arising from the lack of trust in the sharing of data between different companies.

Building a network of trusted participants in a supply chain is both crucial and hard. Only known parties can join the network, thus when considering blockchain technology, it’s the private blockchain, not public, that allows companies and their partners for more transparent and accurate end-to-end tracking in the supply chain.

Benefits of blockchain-based solutions in supply chain include:

• highly streamlined communication and operations;
• cost savings resulting from automation and transparency;
• end-to-end traceability that eliminates risks and improves brand reputation;
• introduction of an ethical supply chain that helps consumers make more conscious choices;
• improved contracting and international transactions.

Food supply chain blockchain use case

One of the most prominent blockchain supply chain use cases is IBM’s Food Trust that benefits both the producers and consumers by introducing transparency and immutability to the supply chain management. This blockchain solution is cloud-based and built on Hyperledger Fabric, an enterprise-grade, distributed ledger platform.

Food Trust (…) connects participants across the food supply through a permissioned, permanent and shared record of food system data.

The system aims to provide a safer and more efficient food ecosystem. Conscious consumers know where the food they put on their plates came from and how it was grown. Food companies build their brand reputation by ensuring better food quality. Manufacturers improve the accuracy and efficiency of tracking the products they offer.

IBM Food Trust customers include Nestle, Walmart, Dole Food Company, and Golden State Foods. Walmart decided to take part in Food Trust after the E. coli outbreak in the US when people from 36 different states were infected with the bacteria after eating lettuce. Walmart saw private blockchain as a technology adapted to help reduce potential food safety risks before they escalate. The company called its food suppliers to join the network and go beyond eliminating damages post factum.

Walmart’s vision is that any customer can scan their bag of lettuce and immediately see where it’s been. [source]

Since then, there has only been one incident of a recall from Walmart for romaine lettuce due to E.coli suspicion. There is still room for improvement in regards to transparency and traceability.

Learn more about why and how to use blockchain for enterprise applications in this post >>

Insurance

The insurance industry consists of various players that offer services that tend to life, health, property, casualty, accidents, and business needs. The list of things to insure is growing with services designed to help protect clients from kidnapping or a sudden loss of a beloved pet, to pandemics-related events that trigger insurance claims. A private blockchain can help automate claims function, bring cost savings and fraud mitigation in the nexus of the insurance industry.

Insurers have to process and share evidence-based data within a complex network of connections: the insurer, the insured, entities that remove the effects of damage, and public authorities, etc. Blockchain allows for real-time data sharing between various parties in a trusted and traceable manner. Private blockchain network mechanisms protect privacy and sovereignty without centralizing the data among multiple parties.

Blockchain also ensures that all the executed transactions are permanent and timestamped. No one can modify the data, which prevents any breaches. It is especially useful when complying with regulations. In the light of any legal changes, each contract has to be amended and the insured person must be immediately informed about the scope of the changes. Usually, such information is then mailed in writing under pain of nullity or sent via certified email. In particular, the latter method is a source of fraud. By moving insurance claims onto an immutable ledger, blockchain technology can help eliminate these sources of fraud in the insurance industry.

Benefits of blockchain-based solutions in insurance industry include:

• consolidation and digitized tracking of data that speed up and automate insurance claims;
• higher safety and privacy standards, tamper-evident distributed ledger technology gives a guarantee of the immutability of documents that are kept elsewhere;
• a possibility to build robust and efficient products, adjusted to changing customer needs;
• scalability enabled by the HLF modularity and design.

Insurance blockchain use case

OpenIDL network is a blockchain platform for efficient, secure data collection and sharing within the insurance industry.

Insurers are hesitant to provide access to their data or claims policy. At the same time, regulators need to gain access to data and consumers must be protected. The backbone of the project, Hyperledger Fabric, offers real-time, automated, secure, and permission-based collection and sharing of sensitive data, while a carrier still owns their data and can decide to give a party authorized access in the context of a regulatory data call.

Healthcare

Healthcare is one of the biggest industries where multiple parties need to cooperate efficiently, generating thousands of data transactions along the way. Sensitive healthcare records require additional protection as their unauthorized disclosure creates significant risks to fundamental rights and freedoms. Integrating and improving the exchange of information and workflows to bring the value of aggregated data on a near real-time and cost-effective basis to all stakeholders is an important healthcare industry priority.

Patients, providers, and payers seldom see complete, up-to-date healthcare records. Blockchain-enabled solutions can help enhance trust in sharing data while eliminating problems with data interoperability. Private blockchain technologies also meet high security criteria for data confidentiality, privacy, and access control.

Benefits of blockchain-based solutions in the healthcare industry include:

• sensitive medical data remains secured and shareable with only the parties authorized for access at the moments when they need it,
• improved coordination of inter-organizational information exchange across health care entities,
• blockchain immutable log can streamline care and prevent costly errors,
• lower costs and impact on access and quality of care.

Healthcare private blockchain use case

EHRs — electronic health records — hold various kinds of personal and sensitive data exchanged across the network of healthcare providers and payers. A robust blockchain platform has to be scalable and handle millions of transactions every day. With this in mind, the team behind the Change Healthcare project created a system that supports rapid throughput to expedite the claim’s life cycle.

Hundreds of thousands of physicians, hospitals, and other providers as well as commercial and government payers rely on the network every day to process claims representing more than $2 trillion each year.

e-Commerce

The e-Commerce industry is a competitive environment measured by customer power. The price and quality of the goods is no longer the only basis of conscious consumers’ purchase decisions. They want to know where and how goods were made. Sustainable development and corporate social responsibility have become an important part of the e-Commerce industry policy. Smart e-businesses listen to their consumers’ needs and want to take care of the natural environment, save resources in the production process, choose verified suppliers who produce locally or provide appropriate working conditions for their employees.

Permissioned and private chains can often be the preferred choice for e-commerce companies when it comes to their supply chain and bringing trust into multiparty operations. This blockchain model ensures data authenticity and unforgetability and provides greater visibility across all supply chain activities. Nevertheless, we need to remember that e-Commerce can also benefit from public blockchain, e.g. by offering cryptocurrency transactions for their customers, or hybrid blockchain models.

“You might have Ethereum or Steller on [the] front end or Hyperledger or Corda on [the] backend — not that the consumer will care, they will learn blockchain means trust.” [source]

Blockchain technology is beneficial both for e-businesses and consumers. It can validate and authenticate data transactions in inventory management, payment processing, product descriptions, and other business activities. And the results of batch quality control recorded on blockchain boosts consumers’ confidence in the products that they are offered.

Benefits of blockchain-based solutions in e-Commerce include:

• highly streamlined communication and operations;
• cost savings resulting from automation and transparency;
• end-to-end traceability eliminates risks and improves brand reputation and consumer loyalty;
• introduction of an ethical supply chain that helps consumers make more conscious choices;
• improved contracting and international transactions.

e-Commerce private blockchain use case

TrustChain is a blockchain based on Hyperledger Fabric that changes the way the jewelry industry operates. It allows anyone in the supply chain to verify the provenance of the rings. It tracks and authenticates diamonds, precious metals, and jewelry from the mine to the retailer and hands of the consumer.

The project eliminates pain points like relying on a scattered series of records, many available only on paper, introducing faster and more accurate and cost effective ways of selling precious stones. The project is still under development and the main challenge is to bring the technology gap.

IoT and blockchain technology

Imagine a city where interconnected technology works seamlessly to improve public safety, transportation, energy efficiency, economic development and operating expenses. In line with the global trend of transforming cities into smart and safe places to live, more and more investments are made in digital transformation. Most smart city solutions rely on a combination of core technologies such as computing, storage, databases, private blockchain, big data, real-time stream processing, artificial intelligence, machine learning, and the Internet of Things.

Currently, the biggest challenge for cities is to create data processing systems to automate data interpretation processes with interoperability in mind. This way, a city gains real-time knowledge about how it and its inhabitants operate. For this purpose, it is important to obtain reliable information in a secure way from sensors. Because all elements of the IoT ecosystems, sensors and smart home devices, are vulnerable to cyber attacks. For example, hacked household appliances can be programmed to break down faster, an expensive machine in machinery parks — robots — could be altered so that a possible failure is covered by the manufacturer’s warranty terms. Implementation of private blockchain technology allows before all else to achieve data integrity, but also to authenticate and validate transmitted data. These features enable mitigating risks and conducting audits for the affected parties to assert their rights.

Benefits of blockchain-based solutions in IoT projects include:

• the ability to scale IoT solutions;
• a sufficient device identity, security, and interoperability.

Key takeaways

Blockchain technology enables industries to remove operating costs and automate operations. Private blockchain in particular solves problems of limited trust between collaborating organizations, when other technologies have failed. It removes underlying friction when validating transactions, introduces transparency, improved security, and immutability.

Among various private blockchain frameworks, there is Hyperledger Fabric — a private permissioned blockchain that fits best for ensuring transparency for groups of organizations that do not fully trust each other.

| Why Hyperledger Fabric?

It is a highly customizable private permissioned blockchain with fine grained permission control and strong consistency of the data.

Check out Hyperledger Fabric cheat sheet >>

Originally published at https://softwaremill.com on October 8, 2021.

Private Blockchain not only for FinTech was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most popular enterprise-grade blockchain frameworks is Hyperledger Fabric. The solution is highly-modular and designed by IBM for industrial enterprise use. Why is Hyperledger Fabric such a strong player among blockchain technologies? Let’s find out.

What is Hyperledger Fabric?

Hyperledger Fabric is an open source blockchain framework, see the source code and the documentation, first released in 2015 and now available on all major clouds: Google Cloud, AWS, Oracle, SAP, and more. Fabric’s modular architecture and versatile design fit a broad range of industry distributed ledger use cases. Blockchain applications built on Fabric are enterprise-ready and provide high security, scalability, confidentiality, and performance.

Fabric is a part of a bigger entity — Hyperledger. It is an initiative created by IBM’s Linux Foundation with the aim of advancing business blockchain adoption through global open source collaboration. The platform encompasses multiple projects, each built for a specific business purpose, one of them being Hyperledger Fabric, and unites a growing number of developers and various organizations.

Hyperledger is an open initiative, any company that wants to actively support the growth and evolution of enterprise blockchain can join. At SoftwareMill, being rooted in the open source Scala community, we built a tool, Fablo, that helps developers easily kick-off new Hyperledger projects and experiment with network topology. There is a tremendous value in building products and services on top of the Hyperledger blockchain. Why? More about this is coming.

Enterprise-ready blockchain technology

Hyperledger Fabric is a framework for private permissioned blockchains. It’s best suited for ensuring transparency for groups of organizations that do not fully trust each other.

Fabric helps organizations keep their information for authorized parties only and is designed for entities that want to have more control over data and more privacy with fine-grained permission control.

The study from 2021, conducted based on a literature review, shows that Hyperledger Fabric is the most promising and useful blockchain framework for various industries when compared to other blockchain frameworks like Corda or Multichain.

“Fabric, Ethereum, Quorum, Multichain, and Corda have respectively an average grade of 4.2, 3.3, 2.2, 2 and 2.2.”

In reality, the final selection of a framework for a specific case study is always a trade-off. To make sure a given framework fits specific business requirements, it is always good to start from a Proof of Concept (PoC). PoC is the starting point for any enterprise blockchain development and lets you verify in a cost-effective way if your idea will function as envisioned.

In fact, the growing number of Hyperledger Fabric’s use cases is a visible proof of the maturity of the tool and the strength of the community around it, making it a go-to framework when investigating blockchain adoption in enterprises.

Modular architecture and scalability

When designing blockchain applications, making sure that specific industry, technology, and organizational requirements are met is crucial. Thus, the phenomenal modularity of Hyperledger Fabric is a valuable feature from a business perspective. It enables innovation and optimization for a broad range of industry use cases.

Hyperledger Fabric allows developers to build off of what they originally created, making their systems scalable. Usually when you start with a private blockchain PoC, you want to start small, but later grow the network of more internal and external partners. Thus, the challenge of scalability is about not just transaction speed but, more importantly, the size of the ecosystem.

“The architecture of Fabric naturally supports sharding, where the shards are the channels themselves hosted on independent ordering services. This means, as you approach the limits of an ordering service’s ability to adequately handle the transaction load of its current set of channels, you can spin up a new ordering service to host the new channels.”

On top of such flexibility, Hyperledger Fabric’s plug and play design gives unlimited network configuration options. You can add and remove different components as you please, taking into account different business needs or desired technologies like various databases or Certificate Authorities.

The flexibility of Fabric comes also from the fact that this framework is language-agnostic. Blockchain systems and smart contracts can be written in any programming language. This means that most enterprises already have the skill set needed to develop smart contracts with Fabric or it’s easier for them to look for professionals and outsource their blockchain development.

Privacy by design

Privacy is a reason why companies look at private blockchain in the first place. They need distributed ledger technology to keep confidential information for authorized parties only to bring trust into their business.

Hyperledger Fabric offers a rich system of permissions that allows flexible allocation of read and write access to transactions to various organizations in the blockchain network. Within the blockchain network, the permissioned parties are offered public and private keys, so they can only interact with the ledger as themselves.

In practice, if you only want certain members of your supply chain to have visibility on a transaction, you can have a private channel that gives permission to only those members for that particular transaction. When your consortium needs more private channels, but for different groups of members of the network — you can create new channels and scale the system.

Fabric also addresses a very important privacy issue that other blockchain technologies don’t take into account. Blockchain solutions are immutable — data that has been added to blockchain ledgers cannot be deleted. This presents a problem from the GDPR perspective. When developers write the solution in a good way using Fabric, it will be GDPR-compliant and will respect GDPR requirements for data storage. More about it coming soon on our blog.

High performance with strong data consistency

Performance and scalability are two key characteristics of any platform. In terms of most of the Hyperledger projects, both will directly relate to end user satisfaction and, ultimately, adoption of a project. Hyperledger Fabric has a special Performance and Scale Working Group established that serves as a cross-project forum for architects and technologists from the blockchain community to exchange ideas and explore the performance and scalability aspects of the Distributed Ledger Technologies projects.

Hyperledger Fabric performance is highly related with smart contract design and the data model beneath. The framework guarantees strong consistency of the state and, at the same time, promises to perform hundreds of transactions per second.

Hyperledger Fabric favors consistency over scalability. When there are many conflicting updates, the overall performance will decrease. The crucial thing to keep the performance high is to properly design the data model and smart contracts. We specialize in this in our blockchain projects. Here’s Kuba, our Blockchain developer, explaining the issue.

What does it mean for the business? For an enterprise application, it is far better to immediately have a consistent final state, rather than the state that after a given period of time will eventually be consistent. This is one of the dimensions where Hyperledger Fabric outruns public blockchains.

Supported by mature community

The Linux Foundation is one of the largest governing bodies of the open source initiative in the world. It means that its tools are developed and continuously supported by a large number of developers. The project is appreciated on GitHub (check out its number of stars) and has an extensive and well-written documentation.

Hyperledger also gathers non-dev members. They have the opportunity to participate in unique, wide-reaching networking and learning programs, where they can get to know the toolset, business use cases, and later contribute to the global blockchain projects that change the way many companies operate and work together.

Why should SoftwareMill help you with Hyperledger Fabric?

• Hyperledger Fabric is a difficult tool. It is complicated due to its flexibility, modularity, and ways it ties consistency with high performance. Developing enterprise-ready blockchain requires a lot of knowledge that cannot be easily acquired.
• In the beginning, you will need a Proof of Concept. Developing a blockchain PoC would require an investment of time, money and resources. Nevertheless, it will help you start small and invest far less than in a full-blown blockchain system. In reality, you’d need to get your hands-on supporting technologies and the help of experienced developers.
• Our engineers are hands-on with various DLT technologies: Hyperledger Fabric, Ethereum, Bitcoin, Solidity, and smart contracts design, and have a portfolio of successfully delivered projects.
• Besides consulting and developing commercial blockchain solutions, we are involved in the blockchain community. We contribute by developing open source projects and sharing our know-how at IT events and on our blog.
• Fablo tackles the complexity of setting up and managing a Hyperledger Fabric network. It suits CI and testing purposes best. Check the source code, the introductory post, or the demo video.

Want to discuss your project? Meet with our Blockchain Team to get expert advice.

Originally published at https://softwaremill.com on October 1, 2021.

Why Hyperledger Fabric? was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trust is the foundation of every business relationship. When there’s a lack of it, a conventional way to make cooperation possible is to introduce an authority in the form of a third-party entity. Today, almost every transaction made in the world is controlled by a third-party, but this generates costs and is time consuming.

Hyperledger Fabric changes that. This open source, industry-focused implementation of blockchain technology, introduces trust, accountability, and transparency in business settings. Any industry that would benefit from a higher level of security, privacy, and performance can consider leveraging private blockchain to reshape the way it operates and exchanges information with its business partnership network.

How does private blockchain work?

When companies interact with the help of a third-party entity instead of directly with each other, simple processes turn into lengthy procedures. The lack of trust introduces friction. There is a need for a trust enabler that guarantees seamless transactions where any personal data and sensitive corporate information is secured from unauthorized access.

To address the above-mentioned challenges in multi-party cooperations, Piotr Hejwowski explains blockchain core features like:

• immutability,
• replicaction,
• and smart contracts,

and looks at them from a business perspective to determine when there are potential determinants of a successful blockchain adoption. Find out more in his post: “Do you need private blockchain?”

The main takeaway is that the private blockchain architecture puts emphasis on enabling trust. By design, it offers control over the logic and sharing of information within a set of known and authorized parties.

On top of being tamper-proof due to the mechanisms mentioned above, blockchain provides a cryptographic history of data operations. It makes it even more resistant to failure because any information on the blockchain is fully auditable.

From this point of view, blockchain is best suited for applications where it is required to have a so-called “ the only, transparent source of truth “ that a company can use to achieve data privacy and control over sharing sensitive information when collaborating with external business partners.

Private blockchain benefits for business

Security

In a business context, it is necessary to protect sensitive corporate information and customer data. Blockchain is considered to be one of the most secure technologies. It ensures that data is tamper-proof, traceable, and trustworthy. Here’s how Hyperledger Fabric provides secure and trusted infrastructure for business transactions.

The extra layer of security comes from a fine grained permission control and data integrity embedded into the blockchain technology. Businesses that set up private blockchains generally set up a permissioned network and define rules for data sharing and visibility for other participants of the network. Anything recorded in the ledger can never be deleted, which later helps to facilitate audits and ensures data safety.

The ability to restrict access for some participants also reduces the likelihood of outsider attacks while facilitating the hierarchy rules and data access control in the enterprise environment. A blockchain owner can choose to permit only certain nodes to perform the transaction verification process. And later only the newly verified transactions are communicated to the rest of the network. Thus, in practice, only given parties of the network are granted permissions to access certain types of data and execute specific functions. This is an efficient and secure way to implement sensitive business processes that use sensitive corporate information.

Data privacy

You already know that the blockchain owner controls the access to the network as well as the participants’ visibility. This serves two essential needs of a corporate environment. Businesses that decide on private blockchain adoption do it to make sure they know who they’re dealing with and to ensure unauthorized participants won’t access sensitive transaction data.

Private blockchain helps organizations keep their information for authorized parties only. It provides a high level of privacy for any enterprise and is one of the main reasons why to implement the blockchain technology in the enterprise scenario.

Performance

Because there is a limited number of participants in the private blockchain network, private blockchains are faster and can process a higher number of transactions per second. Unlike public blockchains, private networks do not depend on the price of gas. They take up a lot less energy because they operate on a different type of a consensus algorithm to reach an agreement over a transaction.

Additionally, when speaking of Hyperledger Fabric, its performance is highly related with the smart contract design and the data model beneath. Transactions are automated with smart contracts which increase efficiency and speed. Both the smart contract design and client application need a special care of experienced developers to utilize the blockchain technology.

Scalability

The most important question when implementing a new technology is: “Does it scale?”. Usually when you start with a private blockchain PoC, you want to start small, but later grow the network of more internal and external partners. Thus, the challenge of scalability is about not just transaction speed but, more importantly, the size of the ecosystem.

“The architecture of Fabric naturally supports sharding, where the shards are the channels themselves hosted on independent ordering services. This means, as you approach the limits of an ordering service’s ability to adequately handle the transaction load of its current set of channels, you can spin up a new ordering service to host the new channels.”

Here’s more about how Hyperledger Fabric performs at scale by IBM experts.

Enterprise-oriented

Businesses looking to reap the benefits of blockchain technology most often turn to Hyperledger Fabric. It is flexible and business-oriented. Its rich system of permissions, modularity, and unlimited possibilities of network configuration, as well as high performance with strong data consistency, are the features designed specifically for enterprise needs.

Hyperledger is developed by the Linux Foundation and supported by IBM. Discover some success stories of companies like Walmart, Sony Global Education, British Columbia, and more that are utilizing the value of private blockchain.

Thinking of a blockchain PoC?

Thinking of launching a private blockchain of your own? We can help! Let’s discuss how we can turn your idea into a successful project.

Originally published at https://softwaremill.com on July 1, 2021.

Private blockchain benefits explained was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

👶 Junior Developer
💻 Mid Developer
🚀 Senior Developer
🧙 Software Architect

But how does this growth actually happen?

If we examine the true drivers, it might turn out that developers grow by spending time writing code and documentation, collaborating with other developers, using various stacks, and solving different problems.

Even though you might have many years of commercial experience in your resume, your public GitHub profile has a huge impact on your software career. It’s your business card in the software world. Not convinced? Check out my previous post Why contribute to open source?

Contributing to open source projects might be intimidating, but it’s worth getting out of your comfort zone and getting involved. Don’t let inexperience in a given tech stack or a library, or any other difference hold you back!

Here are just 3 steps, the best and quickest way, to become an open source contributor.

Say you’d like to get involved

Start from picking the stack and go to “the chats”. To make it easier to establish contact, oss maintainers always set up a dedicated slack or gitter channel or a discord server, or more and more popular, Matrix. Approach library maintainers there and say you’d like to get involved.

Here’s a list of some popular Scala and Java projects and their communication channels:

• Zio — discord server
• Cats — gitter channel
• Akka — gitter channel
• Kafka — Jira tickets
• Scala — Scala contributors forum
• Spark — gitter channel
• OpenJDK — census
• Hibernate — follow this guide
• Apache Commons — everything happens on this mailing list
• Micronaut — gitter community
• Quarkus — GitHub page
• Spring — GitHub page

There are also developer tools that need contributions. The general rules here are the same.

• Scala Metals — gitter chat
• Zio intelliJ — #zio-intellij on the ZIO Discord

GitHub Docs encourage library maintainers to apply the good first issue label to issues in their repositories to highlight opportunities for people to contribute. When looking for something on GitHub to match your needs, search for issues and pull requests, go to isses in a repository and narrow the results using label qualifier.

Another shortcut to find your first repository to contribute to is checking the list created by Masato Ohba. Using his script, he puts plenty of issues waiting for beginners’ contribution into this spreadsheet.

Do not be afraid of the docs

Documentation and usage examples might sound boring, but are a good way to get to know the project, and contribute something useful. You’d be surprised how many people resign from using a project as they can’t find a good, working (!) example, or a step-by-step tutorial aimed at beginners. Working on docs will allow you to learn the very basics of the software in question. It will make it easier for you to make meaningful contributions to the code later.

Important information for the first timers. Always start from the README.md file in the repository which contains rules on how to use and set up the project, and (if present), CONTRIBUTING.md, which outlines how to collaborate in the project.

Improve the tools you already rely on

It’s much easier to make time for things that are a part of your current work assignment.

If you’re using an open source software, library or framework, and you find a bug in it, open an issue. Make actual contributions and take it as an opportunity to demonstrate value, build trust, and gain skills. Even starting from a small patch, that gets merged, will build up your confidence. And finally, you’ll be able to use it in your project, and ship things faster.

Majority of the projects follow a standard fork and pull model for contributions via GitHub pull requests.

An ideal path to meaningful contribution can look like this:

• Find an issue
• Let library maintainers know you are working on it
• Build the project with your contributions
• Write tests, docs and examples
• Submit pull request

What will be your next Scala open source project?

Scala 3 is just around the corner. According to the voices of Scala programmers who took part in te Scala Developers’ Survey, we run at the turn of the year, there are many programmers who are quite content with their choice of libraries and frameworks. But thery also point out areas that could be improved.

When analyzing the survey entries, we identified the projects that attract most contributors. These are Zio and Akka.

This is mostly in line with the most liked libraries out there. And probably shouldn’t be surprising: both ecosystems are growing and hence there’s a lot of work to be done around them.

Most popular Scala OSS projects

1. Zio
2. Akka
3. Scala
4. Cats
5. http4s
6. Play
7. Spark
8. Tapir
9. Alpakka

The results of the survey clearly show that the Scala community is engaged in OSS, also that there’s always a place for more contributors.

When it comes to specific pain points we concluded that these general areas need improvements:

• Relational databases
• Graphics and UI libraries
• ML and data science projects
• Documentation
• Json parsing
• Security and unified observability approach

The Scala community needs you!
Help us improve it.
Contribute.

Want to find out more about the developers’ expectations for Scala 3 and their view on the future of Scala? Download the Scala 3 Tech Report!

Originally published at https://softwaremill.com on March 4, 2021.

What is the best way to contribute to Open Source? was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Programmers share what they’ve learned

Every month we share what we’ve learned in our team. In December Mikołaj, Piotr and Michał discovered:

• how PyCharm is not keeping up with different dependency versions in containerized environments and what to do about it,
• when an empty string can have a monetary value,
• and what’s new in AWS!

Updating PyCharm container interpreters — by Mikołaj Koziarkiewicz

PyCharm is a nice tool, including all sorts of useful features, like the relatively-recently added ML-based code completion. Unfortunately, it can also be a bit…​ uneven at times.

One of such problematic areas is operation with containerized Python interpreters and environments. While PyCharm made great strides over the last year or so, it still has some quirks that need to be worked around, like diagram display, which I covered as a part of a dedicated blogpost.

The following note also deals with working on a containerized interpreter — specifically a docker-compose one — but here, I’m going to discuss another aspect of this kind of tool integration.

Namely, recently I’ve been rather rapidly experimenting with different dependency versions in containerized environments, and it turned out that PyCharm simply wasn’t keeping up — it was still displaying “old” versions.

Now, the first thing I had learned (a while ago) is that, in PyCharm, these issues are often the same for containerized interpreters and remote interpreters, e.g. SSH connectivity; I’m guessing there are some common underlying components there (which makes sense). So, off I went to look for an answer.

Unfortunately, none of the workarounds listed in issues such as this one managed to provide a resolution (including the legendary Invalidate Caches and Restart). Even the new “Rescan Available Python Modules and Packages” feature mentioned in this issue didn’t help at all.

Fortunately, I’ve eventually arrived at two possible solutions: an easy way, and a slightly more involved way. Hopefully one of those can help you with the problem, depending on the PyCharm version you’re using.

The easy way, suggested to me by our very own Maciek Opała, (thanks!) is really easy. All you have to do is go to the directory holding your docker-compose spec, and rebuild it with:

docker-compose build

That’s all! This certainly works on the newer PyCharm versions, like 2020.3.

The more involved way consists of the following steps:

• Ensure you only have the affected project running in PyCharm (i.e. close all others). This is just a safeguard against deleting another interpreter accidentally.
• Go to the Python Interpreter settings for your project.
• Click Show all, and then delete the current interpreter with the “minus” button.
• Remove the docker_interpreter:latest image from your local repository. In the console, this would be:
• docker rmi docker_interpreter:lates although you may need to force it with:docker rmi -f docker_interpreter:latest depending on the state of the current containers.
• Add the interpreter again.

You should now have the updated dependencies proudly displayed in your Python Interpreter settings. No restart, no cache invalidation required. Unfortunately, you have to repeat this every time you change your dependencies — but it beats the alternative.

The value of an empty string — by Piotr Buda

Would you say that an empty string can have any monetary value? Let me tell you, it can. Recently, together with Grzegorz Hejduk, we started a new project that would use Ethereum smart contracts to execute some arbitrary logic, whereas Scala backend using Web3j would monitor Ethereum blockchain and invoke our smart contracts when necessary.

We tested our integration on the Ropsten test network, had tests using Ganache and everything looked good, so we proceeded to deploy smart contracts on the mainnet.

Our backend finally detected an event of interest. It proceeded to execute our main smart contract and that’s when things went sideways. The result? On Etherscan I noticed that there’s a failed transaction that used all gas provided for it. I tried to debug that transaction with truffle and couldn’t load anything meaningful, also no breakpoint I’d set would stop the debugging process. I was puzzled and that’s when I discovered that:

• sending a transaction to an empty address actually… creates a smart contract on the network
• we didn’t provide our smart contract’s address in configuration — it remained a default empty string!

Since our transaction was actually a method invocation on a contract, it failed, but drained all gas in the process and because we used web3j’s DefaultGasProvider and its settings that configuration mishap cost us 0.16 ETH or $100 at the time.

How to avoid such mistakes? We use ZIO config module with Typesafe config but now we want to move that to pureconfig and enforce all Ethereum addresses (defined by tagged types) to be non-empty. But that’s another story for another post.

AWS re:Invent — new features and services — Michał Matłoka

AWS annual conference — re:Invent has been held online this year. This month I’ve learned about new services and features AWS is planning to bring to us in the near future. So far the most interesting for me are:

1. AWS Lambda 1ms billing and Container Image Support — previously code executions times were rounded to and billed per 100 ms. Since now lambdas will be billed per 1 ms. In practice this may result in big cost savings. What is more, AWS Lambda supports container images now. This may be quite useful for cases where non-standard execution environments are leveraged.
2. Amazon Managed Service for Prometheus and Amazon Managed Service for Grafana — Prometheus and Grafana are open-source monitoring-related solutions used in many projects. AWS starts to offer their managed versions.
3. AWS Fault Injection Simulator — have you heard about Netflix Chaos Monkey before? It is a tool related to introducing failures in your system in order to detect application weaknesses. In 2021 AWS plans to launch their own tools, whose role will be quite similar — to inject failures, throttle APIs, simulate outages and others.
4. AWS CloudShell enables access to AWS CLI via AWS Management Console.
5. VPC Reachability Analyzer is a new tool helping to troubleshoot issues related to VPC misconfigurations and services reachability. It is quite simple — you just need to define source and destination of the traffic and the analyzer will check if they are accessible and what is the request path.
6. Amazon S3 — Strong Read-After-Write Consistency — it may not be a widely known information, but S3 was so far eventually consistent. After new changes all reads performed after writes are now strongly consistent.

AWS re:Invent has been a huge event with a lot of talks and tracks. It is not over yet so we can count on new features and product announcements within the next few days.

And what have you learned in December? Let us know! :)

BTW, we are always looking for outstanding professionals to join our team!

Questions? Ask us anything about remote work, how does the cooperation with us look like, what projects do we have, or about anything else - on the dedicated Slack channel 💡

TMWL Dec’20 — PyCharm container interpreters, Ethereum in Scala and AWS re:Invent was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Programmers share what they’ve learned!

Every month we share what we’ve learned in our team. In November Marcin, Michał, Paweł and Tomasz discovered:

• CSS Grid — a more declarative and easier to manage responsive approach to layouts;
• how to improve Docker images security with Trivy;
• tips and tricks for parallel processing in Python;
• Notion — a new kid on the block in the productivity space.

CSS Grid: template areas for declarative layouts by Marcin Baraniecki

Grid is the latest addition to layout systems available in CSS. It’s also the most powerful way of structuring the elements, working in two dimensions simultaneously (unlike flexbox, which works mainly in one, chosen dimension).

The core tenet of Grid is the idea of rows and columns spanning the container and defining “lanes” that might be occupied by elements, horizontally or vertically. The layout can be defined imperatively, using properties like grid-template-rows, grid-template-columns (for grid container) and grid-column, grid-row (for items).

There is, however, another approach, more declarative in nature and — in my opinion — easier to manage, especially with responsive layouts. The idea is focused around two CSS properties: grid-template-areas for the container and grid-area for elements. Use the former to visually describe — almost “draw” (with text) — how you would like your named elements to be structured within the container, and then reference those names with the latter.

Here’s an example:

This is a very simple case, where header elements (left and right) will occupy the top row, followed by the body in the middle and two footer elements side-by-side at the bottom.

What’s more, it’s very easy to quickly declare the desired layout for eg. mobile devices. Let’s keep all elements in a single column — the only property that has to change is the textual declaration of grid-template-areas property:

Check out the full example here. Make sure to resize the preview area on the right to see how the layout is changed for each breakpoint.

To sum up: the grid’s template areas allow to declaratively define the desired layout by almost “drawing” the structure with the text. Moreover, it takes only a single property — namely grid-template-areas — to be changed in order to completely alter the order, width, height — in general, the full structure of elements on a page.

Docker images security & Trivy by Michał Matłoka

Security is lately one of the most important topics. At the same time, Docker container-based systems are widely used. Unfortunately, base images often contain vulnerabilities. How to check that? One of the useful tools is Trivy from Aqua Security. It is a simple command line scanner, which allows you to check if there are any issues with given Docker images. It is enough to install the tool, and run a simple command trivy image <image-name>. It is possible to integrate it into your CI flow.

What are the results? Let’s take a look at the JVM world. openjdk:11-jre is an official OpenJDK image. It is based on Debian 10.6 and Trivy finds 161 vulnerabilities in it, including 26 with high severity. Why so many? Image contains many tools which are not really needed for most applications during runtime, also some outdated packages. So what can you do in such a situation? Well, the easiest way is to change the base image to a different one. AdoptOpenJDK project releases their own images, e.g. adoptopenjdk/openjdk11:alpine-jre — based on alpine 3.12.1. According to Trivy it contains 2 medium severity vulnerabilities (freshly found out). What is more, this image has a size of 150MB, where official, Debian-based has a size of 285MB.

It is worth checking what is included in base images you are using in your projects. If you are interested in Docker security, you may also take a look at Distroless Docker Images.

Parallel processing in Python by Paweł Stawicki

In many languages we use multiprocessing. In JVM languages, like Java or Scala, usually it’s achieved by running many threads. In Python however, popular tool is multiprocessing.Pool which takes a one step more. It runs multiple processes. By default (on Linux) it creates new processes by fork() — which copies state to the new process. It’s important to note that all the state accessible by child processes is a copy, so changing it doesn’t change the parent process state.

Pool has some methods to run tasks in parallel. Obviously, those tasks cannot change a parent’s state, but can return values, so it also encourages pure functions ;)

Below is a short summary of functions of Pool that can be used to put some more CPU cores to work:

• map— simple function that runs subtasks in separate processes and returns a value. It’s parameters are a single-parameter function to run, and a list of arguments, each passed to a separate function call. Example:

• starmap — like map, but usable for functions with many parameters. Each parameters set passed as a tuple:

• imap — like map, the parameters are the same, but this method is lazy. It returns an iterator instead of collection, and the computation is not run until next() is called on the iterator (well, when chunksize is set to 1, but such details are out of scope of this short summary).
• imap_unordered — as the name says, when order of results doesn’t matter.
• map_async and starmap_async — like map and starmap (surprise surprise ;) ) but returns immediately while child processes are still running in the background. Their return type is AsyncResult (check the documentation).

Be careful when using multiprocessing on Windows or Mac. On those systems, multiprocessing doesn’t use fork() to create new processes, but spawn(), which actually imports the module in the Process when it’s created. When it’s done the code in modules’ main file is run. This might cause problems, but it’s easy to avoid — put all the code in modules’ main file under if __name__ == “__main__”.

Notion — a new cool kid on the productivity block by Tomasz Łuczak

Notion is a collaboration tool. It was first released in March 2016. In September 2019 it reached 1 million users. Just after another 7 months Notion hit 4 million users with the company’s valuation at $2 billion. One may wonder what makes Notion so popular.

Notion claims it is an all-in-one workspace. It can be utilised as: a team wiki, a project manager, a tasks manager or as a notetaker. It really depends on one’s needs. Notion is a very flexible tool which enables people to build their own tailored life/business productivity systems without knowing how to code.

Notion approach is based on two building blocks: pages and blocks. Page consists of many blocks. Block can be anything from rich text, embedded youtube clip, google maps, to a… database. Database is a page with records where each row is another page with some specific properties presented in a table view. More interestingly databases can be presented in many forms: table, kanban board, timeline, calendar, list or gallery, as a whole page or inlined on another page, records can be filtered by properties. This approach opens almost endless possibilities.
Notion is especially loved by YouTubers. There is a ton of material like “How I work with Notion”, “My notion setup”, etc:

• The Most Powerful Productivity App I Use — Notion
• Digital Organization + Productivity System — My Notion Setup
• My Notion Life Operating System Overview

As it may seem very appealing, it is not all roses — there are some caveats.

1. First off all Notion has a very limited offline mode. When you load a page it is possible to work with it in an offline mode and after you get reconnected everything should sync back. “Should” is a key word here. There have been reported issues with this scenario.
2. Another thing is that Notion’s web clipper is not as good as the one we know from Evernote.
3. Also there is a public API available for Notion — you can not build automations based on Notion, as you could in Coda.
4. Last thing is that it takes a lot of effort to set up Notion in a way it would work for you — but at least you can.

Overall, Notion is a tool worth checking out and its popularity does not come from nothing.

And what have you learned in November? Let us know! :)

BTW, we are always looking for outstanding professionals to join our team!

Questions? Ask us anything about remote work, how does the cooperation with us look like, what projects do we have, or about anything else - on the dedicated Slack channel 💡

TMWL’ Nov 20 — CSS Grid, Trivy, Python parallel processing, Notion was originally published in SoftwareMill Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.