Architecture.Dev: Strategic Engineering

Poor Man's Approach To start the conversation, let's first examine a wide spread idea of quality management: Quality is a compromise between Scope, Resources and Schedule (The Iron Triangle of Projects); and, Bugs must be prioritized based on Impact and Likelihood. Based on a metaphor it shows why the above idea is a very limited and an impractical approach to software quality management, and it allows us to immediately make two conclusions: software development is a society and QA is the hospital in that society; people that get ill are sent to the hospital to get cured. Quality is non-negotiable: letting people die is always unacceptable; Prioritizing won't improve anything: it won't reduce the number of people getting ill. Principles of Software Quality Management Quality of software is measured through bugs. There is no known or set formula to quantify the software quality, but what is measured is number of bugs and this is the basis to imply the quality. T

1. Your Toolbox: Design Patterns In software design, design patterns are an essential toolbox to ensure your code is broken down into small independent units. This toolbox gets filled one-by-one, a single design pattern at a time. Since the tools can be used in different combinations, quickly the toolbox owner becomes more effective in creating a design that is focused on minimum effort and risk. This is especially true if you write or support software in a team. First you must ensure the tasks - and thus the code - are broken down into independent units. Common symptoms that arise when this is not properly done: engineers waiting on each other code to complete, functionality duplication, merge conflicts, the work of member "a" breaks the work of member "b" (regression bugs), incoherent interfaces - e.g. getX, doWriteX, deleteById; while much more coherent interface would be: readX-writeX-deleteX, or getX-updateX-deleteX. The second issue is in supporting (r

Earlier we discussed Analyzing Software: Technical, Tactical and Strategic Qualities . As a comment pointed out, finding the right candidates is very challenging. This article explores the differences in skills needed, something that might benefit you in selecting the right candidate for the right role. Definitions When comparing people who are an analyst or an expert, many similarities can be found. Both have proper education, and both are for sure not rookies in the field. Thus to help separating the different skills needed for different roles, a more narrow definition of the terms will be used. The Expert : a person who has gained Experience through extensive practice The Analyst : a person who has Analyzed the work of many different Experts The Expert During an interview with a candidate, people start talking about their experience: what have they done. It tends to be that people often repeat their approach, especially if it yielded prior success. Thus almost naturally

Building software always comes with significant investments, but should be only a fraction of the possible long term gains. To ensure the software yields the expected outcomes, not only for the first releases, the first two years, but long term, the software must be developed with different qualities. Long term? How many systems does your organization have, that are 3+ years old and are not limiting the potential capabilities of the company [without reinvesting/rewriting them]?. In this article a small framework to assess the quality of your software is presented. To ensure software is profitable for the company during its full potential, we analyze the software on 3 different levels: Technical, Tactical and Strategic. This can be the first step to improve the earn backs of your technology/software investments. Technical Quality When people learn how to program, the syntax of the language is explained. Next in detail is explained, how to do recursion, with the termination conditi

Failure of Software Design Software systems process data. Either this is computation input/output or persistent data read from storage for processing. To minimize the effort and risk to realize a software solution - - many architects model the data based on the inputs and outputs. They just add some annotations on those models, and voila, it can be written and read from a database! Software design is the process of minimizing the effort and risk of developing your software. Unfortunately, they are not knowing that using the same data perspective for input/output and storage - or in other words, not using different data representations - is one of the biggest reason that the system will be a legacy system, and that needs to be replaced as soon as it is ready. :( Software architecture is the process of making sure that future changes to the needs can be easily accommodated in your software. To explain a bit more, the business needs are constantly changing, therefore the input

In today's world, the systems you are developing are not isolated, they need many different integrations with other external services. From Authentication Systems (using SAML, LDAP, OIDC) to Data and Processing Systems (Malware Analysis, CRMs, Ticketing Systems). Although the number of actual systems to integrate with is vast, luckily the Use Cases and types of integrations are manageable. Here we will discuss popular Use Cases and list integration strategies to accomplish them. Use Case 1: Transfer the User from your System to the External Service In this scenario, the User is working in your system and is now required to access specific functionality in an External Service. The following steps must happen: the service must be located, the user must be authenticated, and the right interface/data must be presented. 1.1 Service Locator Integration Your system understands how to find the specific service, the user does not need to remember the location of the external service

Ask a developer if he is developing the same software as in his previous engagements, and most of the time the answer is "no". On first sight it looks reasonable, if you consider that he has been working on a different project, in a different company, or even within a different industry vertical. But when we analyze the code that is actually developed, this is most peculiar. Code is made up of business logic and "plumbing". Business logic is around 5% of the total code and project specific. The rest is plumbing that is not specific to the requirements of the project. If 95% of the code is not specific to the project, how can it be that we are not writing mostly the same code? The reason is often simple, the business logic is not isolated from the plumbing. This causes the plumbing code to become project contextual; the plumbing code is full of traces of business logic and thus specific to the project. Thus the potential 95% that should be project agnostic can