Where do I get started with data-driven engineering? How can the 3 I’s of data-driven engineering help me get off to a running start? How can I avoid the common pitfalls of data-driven engineering?
A system can be under both stress and strain, but how do they differ? How are they related? Also, why make the distinction?
Language and semantics around system faults are important. For example, what’s so important about differentiating between blocking and masking faults?
In Weinberg’s Why Software Gets In Trouble, he discusses the difference between failures and faults. Although an obviously old concept, I’m finding it to be a novel approach to thinking about these issues (maybe novel to just me).
What is a system, systems thinking, science, philosophy, theory? How are they related? How can they be used?
Is software testing just checking if software conforms to the requirements? Sometimes… but usually the answer is no.
Although the Octopus Deployment Framework is an awesome tool, it has a couple of flaws that frustrate me. Here are a few of the issues that I think would greatly improve the framework.
Octopus allows you to define both intra- and inter-server dependencies. This is one of the coolest things about Octopus. However, defining dependencies is not without problems.
The Octopus Deployment Framework is an internal Microsoft framework used for deployment on some Microsoft teams, but why is it useful?
Expected values are valuable in statistics and in software testing. However, they generally mean different things. How do they differ, and how can one be applied to the other?