Although agile principles are widely used in software development today, many IoT projects are still implemented in the traditional (increasingly outdated) way. As a result, many IoT projects take much longer than planned or even fail completely.

One challenge for development teams in IoT projects is to cover a wide range of capabilities in areas such as hardware, networks, security, cloud platforms, analytics, artificial intelligence, and interfaces (API). These capabilities have traditionally been highly siloed in most organizations. In many cases, sharing and collaboration between “silos of responsibility” works in a very limited way, if at all. A common vision is missing.

However, in IoT projects, development teams need to work in an integrated way towards a common goal. This is one of the main reasons why traditional IoT development using waterfall methods reaches its limits. This starts with project control: an IoT project that is planned and controlled using methods and tools of traditional project management, such as GANTT charts, sooner or later gets out of hand and, in the worst case, ends up in chaos. This is what our experience shows.

Teams in IoT development: Agile collaboration instead of responsibility silos

“Projects implemented with Agile show a 64% success rate as compared to 49% for the projects implemented with traditional methodologies.” –Boris Shiklo, CTO at ScienceSoft.

Agile software development focuses on value creation instead of implementing specific functions. Along value chains, small working parts of the software are created in iterations instead of working towards a complete product (as a sum of functions). In software development, this offers the great advantage that users can provide feedback and change requirements during the development phase without putting the entire project in jeopardy.

This is particularly crucial in IoT projects, as the technical requirements and the interaction between various disciplines and areas of responsibility are usually much more complex than in “normal” software projects.

“IoT projects are successful only if everyone involved works on a common vision. Thinking in silos of responsibility does not lead to success.” – Igor Pshul, Solution Architect.

Agile Software Manifesto (2001) – excerpt

• Working software is more important than comprehensive documentation
• Individuals and interactions are more important than processes and tools
• Collaboration with customers is more important than contract negotiation
• Responding to change is more important than following a plan

In IoT projects, where teams from various areas of the architecture – frontend, middleware and hardware – have to work together in an integrated manner, smooth interaction between individuals is crucial – communication is a critical factor for success. To ensure optimal interaction, there needs to be a willingness within the team to follow a common vision, on the one hand, and project management that establishes collaboration across responsibility lines, on the other.

The role of the project manager in agile IoT projects

The success of IoT projects depends on the interaction between developers from different areas of the IoT architecture. This also changes the role of project management – away from tasks and timelines to people. “People management” instead of “project management”.

The project management goal in IoT projects is to enable developers to take on changing roles in agile teams in any situation “Project managers” – whether “product owners” or “scrum masters” – must be able to dynamically control roles and competencies in their teams and create the conditions to ensure that interaction between developers and the teams runs smoothly at all times.

“Now it’s a team sport to the extreme […]. We have many more releases, but the prototypes are smaller and there are many more components..” – Harel Kodesh, former CTO at GE Software.

Shared vision & vertical orientation in the team

In times when technologies and requirements for software systems are changing faster and faster, architectures are also changing – moving away from individual functions (horizontally) in monoliths to value chains (vertically) in modular systems. Accordingly, the organization of teams in IoT projects must also be vertically oriented. Instead of specialized teams for the development of separate functions, cross-functional teams are created to implement the features of a value chain.

The challenge for project managers, especially in companies that traditionally ” think horizontally,” is to establish a vertical orientation in the team (and in the product). This requires an agile culture and a shared vision for the product and the path leading to the result. If this culture and vision are missing in the team (or even only among individual developers), friction is inevitable and the risk of failure is extremely high.

Overcoming communication barriers

In an ideal IoT project, developers from all areas of the system architecture work together in agile teams. In practice, however, especially in international projects, different languages, time zones, cultures, and ways of working can make collaboration and exchange difficult, and in the worst case even impossible. Here, project management has to build bridges.

Creative workarounds are often needed to resolve communication blockades between teams. Here’s an example from our practice: If collaboration between the software (frontend, middleware) and hardware (firmware) departments is poor – for example, because different languages, cultures, time zones, etc. clash – then project management may have to work with the software team to find ways to develop without access to the hardware. One solution, for example, is to simulate the hardware with the help of a digital twin.

Example: Digital twin helps neutralize communication barriers

In addition, developers from the software team must be able to simulate the hardware. This calls for true full-stack development that goes beyond the scope of “standard” software development. That is why we at voltage IT stand for holistic full-stack development instead of development in responsibility and competence clusters.

Our Vision: 100% Holistic Development in Autonomous Teams

Software development is a team sport, not a solitary discipline. IoT projects are only successful if competencies within and between the teams involved are managed well, strengths are combined, and responsibilities are bundled. The aim is to assemble teams that can solve problems autonomously. The challenge for project owners is to find the ideal balance between control and autonomy.

At voltage IT we follow these principles:

• Responsibilities & accountabilities follow objectives, not roles in the team
  Agile software development is oriented towards value creation instead of features. Responsibilities & accountabilities in the team are distributed in such a way that the features of a value chain can be implemented quickly and efficiently. For this purpose, classic roles and responsibilities may have to be broken up. Specialized teams are replaced by cross-functional teams in which the necessary competencies are combined in the best possible way.

• Full-stack development and competencies in the team, not in individuals
  If competencies are distributed evenly among as many project participants as possible, it is easier and more flexible to form agile teams that are able to develop autonomously. In addition, the distribution of competencies reduces the project risk due to the failure of individual developers (“bus factor”).

• Using agile methods, such as pair programming, to increase autonomy
  Autonomous teams are able to respond to new project requirements and find solutions on their own. In addition, autonomous teams can continuously ensure the quality of development with the help of agile working methods and tools. At voltage IT, we rely on “pair programming”, where developers work together in pairs, develop simultaneously and check quality.

Conclusion: Agile development is perfect for IoT projects

Just as applications in the IoT are organized in a decentralized manner, software development must also be organized decentrally. Agile leadership takes the place of traditional project management based on the waterfall principle. Cross-functional teams work autonomously and holistically along value chains, instead of working off functional requirements in an externally determined and tightly meshed manner At voltage IT, this is not just a vision and a claim, but a successful reality in complex IoT projects.

Worth reading

• How Much Autonomy Should Teams get from Their Agile Leader? (scrum.org)

• Allen Holub on Software Craftsmenship and agile Principles (Video)

Need help? Let’s talk!

For many years we aim to enable companies to make the right IT decisions and to get software systems they sustainably benefit from and manage themselves in the long term. Our mission: Building “reasonable” solutions beyond technology hype.

“Quick & dirty” software development saves time short-term, but can do more harm than good in the long run This calls for rethinking software development and returning to quality craftsmanship. Learn here what it takes to achieve this.

Software that is developed quickly but poorly causes immense damage worldwide – most of it through software failures in operation. According to studies, the cost of failures due to poor software quality in the US was $1.56 trillion in 2020. This is 10 times more expensive than preventing or fixing errors in development before the software goes live.

As software evolves and grows, its architecture tends to become more complex. This makes maintaining the software difficult and error-prone. Moreover, if design, architecture and source code are poorly crafted from the beginning, sooner or later every adjustment, no matter how small it is, can become a nightmare for product owners and developers.

The challenge for developers is to avoid errors in the programming code or to detect bugs as early as possible so that they can be fixed at relatively low cost. To achieve this, software craftsmanship and quality management must interact closely from the very first line of code. The basis for high-quality and sustainable software is already laid in code line 1.

Reasonable software development aims to balance speed and quality in the best possible way. The key is in good software design, created sustainably rather than “quick & dirty”.

Basic Values of our Software Craftsmanship

• Quality: Software should not only work, but also be well crafted
• Added value: We do not only react to changes, but constantly add value
• Team: Not individuals create great results, but a community of professionals
• Cooperation: Productive partnerships instead of just cooperation with customers

Source: manifesto.softwarecraftsmanship.org

Deliver complex software quickly and at top quality

Thanks to advanced tools and methods, software code is nowadays published faster than ever before. This allows companies to develop new features in less time. At the same time, the complexity of functions is growing, which used to take much more time for development and testing than it does today. However, this positive trend reaches its limits when software quality suffers from time pressure and complex requirements.

The challenge: The faster companies develop new functions, the more difficult it is to ensure software quality and reliability. Very short testing cycles increase the risk that more errors will go undetected and find their way into production. Depending on the frequency and scope of software customizations, these errors accumulate and sooner or later let software design and architecture erode. The cost of finding and fixing bugs in a rotten system increases with each customization.

The cost of an error in the software development process

Finding and fixing critical software bugs during operation is 10 times more expensive than finding and fixing them before the software is put into operation. It is therefore worth investing in the prevention of errors through clean code and good software design at the beginning, instead of developing “quick & dirty” under time pressure.

Source: altexsoft.com

The downside of “quick & dirty” development

Software erosion, decay or rot refers to the creeping deterioration of software as a result of poor planning and/or implementation. Indications for software erosion are e.g. the accumulation of program errors, more difficult adaptability, decreasing performance, as well as incompatibilities with new features and future software environments. In the medium term the software gets a “code smell”, whereby the source code still works, but is poorly structured. The software gradually becomes a legacy system and thus ends functionally and economically unusable.

Symptoms of rotten software design

1. Rigidity: the system is difficult and costly to change
2. Fragility: small changes have unpredictable consequences for the system
3. Inflexibility: individual components are difficult to isolate
4. Viscosity: software architecture is difficult to maintain when changed
5. Unnecessary complexity: the software contains infrastructure with no tangible benefit
6. Unnecessary repetition: architecture contains repetitive code structures
7. Opacity: source code is difficult to read and understand

Source: based on Robert C. Martin

Sustainable software development instead of “quick & dirty”

High-quality software depends on high-quality design and code. The path for quality is set in the design, because the plan for a computer software is as important as the plan for a house – poorly designed implementation ends in chaos. The software design defines what is to be built in the form of software code. That’s why both – design and code – require the highest level of craftsmanship.

The role of good software design

Good design costs time and effort today, but pays off by making it easier to develop the software in the future. Poor design saves time and effort in the short term, but creates technical debt that slows software development productivity in the long run.

Source: martinfowler.com

Good versus bad software design

Source: based on geeksforgeeks.org

The role of good software code

The quality and structure of the source code are crucial for crafting software sustainably. If software code is developed quickly and “dirty” due to time pressure and cost restrictions from the beginning, errors will occur causing costs later in the project. Unlike “clean code”, written in a simple and structured way, the costs for adapting “dirty” code grow over time.

Source: geeksforgeeks.org

Only the developer who wrote the “dirty and fast code” is able to cope with it, but after some time and thousands of lines every developer will struggle to understand his own code. And what happens if he/ she is absent, for example due to illness, vacation or because he moves to another company? Then disaster can strike – the so-called “bus factor” illustrates this.

Side note: The “bus factor” quantifies the minimum number of developers in a team who must suddenly disappear from a project so that a project grinds to a halt due to lack of code knowledge. If only one developer knows the code, the risk is extremely high that a project ends up in chaos if this developer drops out. Therefore, we recommend to always share code knowledge within the team. If developers have to work on third-party code, the effort increases immensely, since they need to understand the individual structure before they can adapt it. And even if they do, it is still hard to assess the risks of changes, since hidden links in the system are not easy to identify. “Clean code”, on the other hand, makes it much easier for developers who haven’t written the code themselves to understand structures and make changes with minimal risk.

“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.” –Grady Booch (Aauthor of Object Oriented Analysis and Design with Applications)

Recommended reading on the importance of architecture for software sustainability:
Software Architecture for SMB: Microservices vs Monolith – What’s the best solution?

Agile software development according to craft principles

Developing software quick & dirty causes immense technical debts and makes product owners in companies suffer. That is why we at voltage IT follow the principles of “Software Craftsmanship” in solution development, which consistently prioritizes sustainable quality over short-term success.

Sustainable software design and clean code play a central role in our projects. For the implementation we use agile methods and tools:

• TDD (Test Driven Development): The functionality of each software feature is monitored via at least one automated test. This ensures security and confidence in code changes and enables fast development cycles without manual test runs.
• Pair Programming/ Continuous Code Review: While one developer writes the code, another provides ongoing feedback and makes suggestions for improvement. This results in higher quality code while the developer continues working and saves subsequent code reviews.
• Refactoring: Well-made software must be deeply and continuously refactored to remain well-made. With refactoring, the internal structure of existing code is adapted without changing the system’s behavior.
• Continuous Delivery: Code is adapted in very short cycles so that changes remain verifiable for the entire team at all times. This enables avoiding large, hidden software errors in production and to fix smaller defects at lightning speed.

Final words in conclusion: In many areas of our lives, manual tasks could be rationalized by assembly lines and automation, which in many cases has its justification from an economic point of view. Over many years and in many projects we have learned that assembly line work in software development is limited and does more harm than good. Good software still needs good craftsmanship, and that will remain the case.

Worth reading

• Refactoring – Short introduction by Martin Fowler (refactoring.com)
• DesignStaminaHypothesis – Is it worth the effort to design software well? (martinfowler.com)
• Cost of Poor Software Quality in the US: 2020 Report (it-cisq.org)

Need help? Let’s talk!

For many years we aim to enable companies to make the right IT decisions and to get software systems they sustainably benefit from and manage themselves in the long term. Our mission: Building “reasonable” solutions beyond technology hype.

Microservices have been hyped for years, but they are not always the best solution. What small and medium-sized businesses with limited resources often ignore: Microservice architectures are true resource hogs, despite all the advantages they offer in day-to-day operations. Learn more about (often doomed) alternatives here.

To avoid misunderstandings: Microservice architectures are not unsuitable for SMEs as such; however, they do have some pitfalls that should be taken into account. To take full advantage of the flexibility that microservices undoubtedly offer, companies must be able to handle decentralized development and maintenance within their IT organization. This is often a major challenge.

“Companies that don’t have mature teams for software development and maintenance should critically question whether they can really afford microservices..” – Igor Pshul, Solution Architect

Monolithic architectures are often seen as the outdated counter-model to microservices. However, they are not as bad as their reputation, provided they are implemented with a high level of quality. In (often ideologically driven) debates about software architectures the advantages of monolithic architectures are frequently ignored.

Which architectural style is the right one in each individual case cannot be decided by what is technologically currently fashionable. Instead, the key factor is which approach is feasible for a company and is better suited to achieving its business goals. That’ s why we at voltage IT support our customers both objectively and with a clear view to long-term success.

The challenge every company faces sooner or later: by eroding their architecture, software systems gradually become more error-prone and inefficient. Even the smallest adjustments can result in a great deal of anxiety and pain. In the following, we will give advice on how you can prevent this with the right architecture.

Microservice architecture: features, requirements, pros & cons

Microservices represent an architectural style of software applications that consist of small services (microservices). Each individual service is executed in its own process and communicates via interfaces (HTTP, REST API) with other services or systems in the company.

Services are organized around business functions, managed in a largely decentralized manner, and can be deployed independently and fully automated. Microservices can be developed in different programming languages and use different technologies for storing data. Services are implemented using containers that are orchestrated (provisioned, scaled and managed) with Kybernetes.

Challenges:

• Resources: different teams needed for maintenance and development
• Communication: Manage independent deployment units
• Performance: Latency in the interaction of services and systems
• Infrastructure: Redundancies through independent deployment processes
• Security:Every API is a potential point of attack for cybercriminals
• Architecture: Keep decentralized service structure (avoid “monolithization”)

Conclusion: Microservice architectures are flexible in terms of adaptation and further development. However, this requires distributed teams to be deployed and coordinated. With highly distributed systems, companies tend to develop an overhead for administration and communication.

Monolithic architecture: features, requirements, pros & cons

Unlike distributed systems based on microservices, monolithic software architectures combine all functional elements in a single homogeneous entity. The systems’ components are deployed and operated in a common process. Accordingly, these systems can only be scaled as a whole.

The advantages of monolithic architectures largely correspond to the disadvantages of microservice architectures and vice versa.

Modular monoliths: Combining the best of both worlds

What is often ignored in ideological debates about software architectures is that microservices and monoliths are not mutually exclusive. The optimum is somewhere between the two. Smart programmers combine the best of both worlds and create systems that don’t follow architectural styles dogmatically. The key is the business value that results from smartly combining different approaches.

Source: Simon Brown @ codingthearchitecture.com

At voltage IT, we focus on structured software development, which starts monolithically but can take advantage of microservices at any time. We achieve this, for example, by creating a clear vertical structure according to functionalities and developing according to highest quality standards: domain driven design, test driven development, to avoid erosion and tight coupling of individual modules, so that each module can be subsequently extracted to a microservice.

We call this “reasonable” software engineering because we are not guided by the microservice hype, but strategically build the basis for systems that focus on the actual requirements and can be maintained and flexibly developed by companies or their service providers themselves in the long term.

Worth reading

• Microservices – brief introduction by James Lewis (martinfowler.com)
• MonolithFirst – good reasons for starting with monoliths (martinfowler.com)
• Don’t start with a monolith– When monoliths are not suitable (martinfowler.com)
• Distributed big balls of mud – About distributed architectures (codingthearchitecture.com)

Need help? Let’s talk!

For many years we aim to enable companies to make the right IT decisions and to get software systems they sustainably benefit from and manage themselves in the long term. Our mission: Building “reasonable” solutions beyond technology hype.