“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.