BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Software Craftsmanship Content on InfoQ

  • Considering Remote Mob Programming in a High Stakes Environment

    Remote mob programming helped a team in a high-stakes environment to be resilient, work under pressure, and deliver successfully. Setting expectations on the first call and being serious about the reasons for doing mob programming ensured that the team kept doing it.

  • Unlocking Software Engineering Potential for Better Products

    Becoming an empowered team means solving problems rather than shipping features. Empowering software engineers and involving them early in discovery work can result in better products. If we measure outcomes rather than output, we can also hold teams accountable. Supporting software engineers to empower them means trusting them and getting out of their way.

  • Programming Foundations for Test Automation

    Proper programming foundations can improve your test automation, making it easier to maintain testing code, and reduce stress. A foundation of the theory and basic principles of coding and programming can help to bring test automation to the next level. Object-oriented programming principles can help to overcome code smells.

  • Test Automation Requires a Strategy and Clean Code

    Having a good strategy for test automation can make it easier to implement test automation and reduce test maintenance costs. The test automation pyramid and automation test wheel can be of help when formulating a test automation strategy and plan. Test automation code should be clean code, and treated similarly to production code.

  • How to Assess Software Quality

    The quality practices assessment model (QPAM) can be used to classify a team’s exhibited behavior into four dimensions: Beginning, Unifying, Practicing, and Innovating. It explores social and technical quality aspects like feedback loops, culture, code quality and technical debt, and deployment pipeline.

  • Helping Teams Deliver with a Quality Practices Assessment Model

    The quality practices assessment model explores quality aspects that help teams to deliver in an agile way. The model covers both social and technical aspects of quality; it is used to assess the quality of the team’s processes and also touches on product quality. With an assessment, teams can look at where their practices lie within the quality aspects and decide on what they want to improve.

  • How Twitter Automated Data Quality Check Process

    Twitter engineering has recently shared a blog post on how they architected and developed a quality automation platform. Twitter digests and creates thousands of data sets for different data products and applications. The next natural step is to make sure of the quality of the data by adding automation on top of it. In this news post, we explore this architecture in more detail.

  • How We Can Use Data to Improve System Quality

    To understand how systems are being used, we can collect metrics and identify trends over time. The data and insights gained can be used to improve system quality by improving software design or testing patterns.

  • Using the Technical Debt Metaphor to Communicate Code Quality

    With technical debt, we end up paying a gradually rising cost. The technical debt metaphor was intended as a way to help us talk and think about the invisibility of decisions and qualities in code. Kevlin Henney gave a keynote about Six Impossible Things at QCon London 2022 and at QCon Plus May 10-20, 2022. His sixth impossibility was technical debt is quantifiable as financial debt.

  • Google Production Excellence Program "ProdEx": Christof Leng at DOES 2022

    Christof Leng, SRE lead at Google, presented ProdEx, their production excellence review program that helps manage operational risks and promote best practices. ProdEx is a community that builds platforms together, establishes standards and promotes best practices, so people learn from each others and grow. Today they have more than 100 SRE teams signed up and have performed more than 1000 reviews.

  • Technical Debt is Quantifiable as Financial Debt: an Impossible Thing for Developers

    Technical debt can be quantified in various ways, but you cannot precisely quantify the associated financial debt. According to Kevlin Henney, we can quantify things like how many debt items we have, the estimated time to fix each debt item, a variety of metrics associated with our code, such as cyclomatic complexity, degree of duplication, number of lines of code, but not the financial debt.

  • Getting Feedback When Your Colleagues Are Also Your Customers

    Getting and using feedback from colleagues who are also customers using your product can improve the quality of the product and help to improve the way of working. In this situation, it’s easier to receive feedback, but you can get overloaded by it.

  • Applying Observability to Increase Delivery Speed and Flow in Teams

    When we design team and departmental processes, we want to know what’s happening in the software teams. Asking team members to provide information or fill in fields in tools adds a burden and distorts reality. Setting up observability in the software can provide alternative insights in a less intrusive way. Observability in the software can be an asset to organizing teams.

  • How Norway's Largest Bureaucracy Optimises for Fast Flow

    To optimise for fast flow, the Norwegian Labour and Welfare Administration has adopted a teams-first approach. High-performing teams need autonomy, and they also require direction and alignment. Solutions should be adopted by the teams within their context, abilities, and cognitive capacity.

  • Every Question Has an Answer: an Impossible Thing for Developers

    We tend to assume that every question has an answer, which for instance isn’t true when we want to find out what the current time is. Developers should increase awareness of unexpected failure modes, advertise the possibility of failure, and use time-outs to recover from waiting for an answer that will never come.

BT