Abstract: Using qualitative data analysis (QDA) to perform domain analysis and modeling has shown great promise. Yet, the evaluation of such approaches has been limited to single-case case studies. While these exploratory cases are valuable for an initial assessment, the evaluation of the efficacy of QDA to solve the suggested problems is restricted by the common single-case case study research design. Using our own method, called QDAcity-RE, as the example, we present an in-depth empirical evaluation of employing qualitative data analysis for domain modeling using a controlled experiment design. Our controlled experiment shows that the QDA-based method leads to a deeper and richer set of domain concepts discovered from the data, while also being more time efficient than the control group using a comparable non-QDA-based method with the same level of traceability.Continue reading “A Validation of QDAcity‑RE for Domain Modeling Using Qualitative Data Analysis”
Abstract: Continuous deployment can reduce the time from a source code change to a newly deployed application significantly. Increased innovation speed can make all the difference in a competitive market situation. However, deploying at high frequency requires high speeds of discovering bugs in the deployed software. Using the JDownloader file download manager as our example, we present a fitness model to evaluate a continuously deployed software during operation for expected behavior, present the design and implementation of a monitoring component, and evaluate the model and its implementation using data from JDownloader’s multi-million member strong user base. Our evaluation finds that there had been thousands of undetected bugs, and that newly created bugs can be detected and reported 16 times faster than before.
Keywords: Continuous deployment, continuous delivery, immune system
Reference: Rechenmacher, T., Riehle, D., & Weber, M. (2020). The JDownloader Immune System for Continuous Deployment. In Proceedings of the 53rd Hawaii International Conference on System Sciences (HICSS 2020), pp. 6559-6568.
Download: The paper is available a PDF file.
Someone on Twitter asked this question and people loved to weigh in. Most answered: “No, just get an old $200 laptop.” While not wrong, this answer misses the point. Coding, here, apparently means reading and writing code. For that, indeed, any cheap computer will do. However, being able to read and write code does not mean you will be able to build and ship systems, which is what customers pay for.Continue reading “Do You Need a Macbook to Learn to Code? (Coding vs. Systems Building)”
In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:Continue reading “CTO vs. VP of Engineering”
In three previous posts I had reported about our research into problems with product line engineering. Three important specific problems (of several more) were:
- Lack of resources in the platform organizational unit
- Insufficient collaboration between product and platform unit
- Political power play between product units
In previous blog posts we identified
- lack of resources in platform organization and
- insufficient collaboration between product and platform unit
as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.
As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.
We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.
A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.
On Twitter, @arkwrite suggested that a code review should always say something nice and @chaos_monster commented that we need a code of conduct for code reviews. All of this makes sense to me, however, I suggest that we first have a general code of conduct of productive discussions (and most companies have something like it). The two main rules that come to my mind are:
- Separate the person from the issue
- Praise liberally, criticize specifically
Separating a person from the issue makes sure that you focus on the technical problem, not the person. Praising liberally is just good practice, showing how you value a person’s contribution. If you have to criticize for good reason, be specific so that the underlying technical issue is clear and provides a chance to respond.