Quality Software Engineering Challenge

Introduction

So you think it’s easy to be a software engineer / developer? But what does it mean to be a Software Engineer of quality that creates quality software? And what are we actually talking about when we say quality software?

I’m sure we’ll find as many definitions of quality software as you’ll find developers and users. Let’s start with us agreeing to disagree on a few things, my way of defining quality might not be the same as yours and Wikipedia tells us (simplified) that “Software quality” refers to two areas:

• Software Functional Quality – Did we create the correct software?
• Software Structural Quality – Does it work as needed?

With the above simplified “definition” do we really disagree? We can say that we disagree on what software that should be created and what non-functional requirements that should be defined for a specific project, but if the software produced is the correct one and works as it’s supposed to do, then we have quality software, right?

Quality Software Engineering would then be the act of creating quality software it’s the journey towards quality software. As we all know journeys are more fun to do with friends (colleagues) except from when your friends don’t agree with you or don’t travel in the same direction as you. It wouldn’t be much fun (and no quality software) if you all traveled to different places (different goals).

There are a few software engineering practices that potentially could help you as a software engineer deliver quality software. Once again it will be painfully obvious that not all developers think the same about these kinds of principles. Some like them all, some are willing to try something new, some don’t like to be told what to do. At some companies they are required and at others not. Some example would be: pair programming, code reviews, unit testing, integration testing, TDD (Test Driven Development), BDD (Behavior-Driven Development), KISS (Keep It Simple, Stupid!), SOLID, etc.

But once we have managed to create that awesome piece of software we want someone to use it. If we are talking about Open Source Software, OSS, then we even want complete strangers to both use and contribute to our software. But how can we make sure others understand that our software is a piece of quality art that they should use and engage in? What is it that makes another developer stop and say: “Hey, this is quality code that I want to use and even contribute to!”? What is it that makes the difference that makes someone use your piece of software?

The Challenge

This exercise is meant to provide a safe playground for a team of developers to try and stress the importance of creating quality code, using quality engineering practices that others want to use. Even though there will be a winner, in the end this is meant to be a fun experience. Nothing in this challenge is more important than to be friendly.

You’ll receive a fictional mission that will guide you through the requirements to a piece of software that “the customer” need to have implemented. Your mission is to implement those requirements according to the following rules:

1. You’ll be given a number and you’ll be the project owner of project N
2. You are not allowed to write any code for your own project
3. In your own project you are allowed to contribute with:
   • Supporting services such as CI/CD, etc.
   • README, LICENCE and CONTRIBUTE files
   • All things regarding project management
   • Code reviews
   • Any discussions going on in your project using the selected project management tool, such as GitHub, etc.
4. Contributing to others
   • Whenever you have time, you should contribute to another project. Start with project N+1. If this project doesn’t have any work for you or if you already contributed, then turn to N+2, etc. When you have contributed to all other projects start from the beginning (except for your own project).
   • Any communication with the project owner as part of you contributing code should be done using the projects selected “Project Management Tool”, such as GitHub, Azure DevOps, etc. No talking directly to a project owner.
5. You’ll have a buddy that you can talk to with number N-1. If that buddy is unable to talk to you, your secondary buddy has number N-2, etc.
6. You need to release versions one at a time, you can never skip a version.
7. The code repository should always be kept in a state where it delivers end user value.

The End

When time runs out, each project owner will present their initial requirements and the current state of the project.

Initial Points

Everyone starts with 5 points. Anytime anyone is found cheating by talking to his/her developer directly, one point will be lost.

The Vote

After all presentations are done. Everyone will have a short period of time to give each project 4x5 points for the four topics described below.

• Quality Code (1-5)
  • Did we create the correct software? Have we fulfilled the requirements?
  • Does it work as needed? How do we know it works?
• Quality Engineering (1-5)
  • How well planned was this project?
  • What processes, services, principles are enforced in this project that helps developers provide quality code?
• Community and presentation (1-5)
  • Is it likely that this repository will catch another developer’s attention?
  • Do you feel that this project makes it easy for you to contribute?
• Contribution to other (1-10)
  • How much code contribution did you receive from this participant?

The Winner

The project with the most points wins (30 is max)

Take Away

Consider what it was that went well and what didn’t go so well. Given the chance to run a real software engineering project, what would you do differently?

Is there anyone that participated that you look up to when it comes to quality engineering? If so what is he/she doing that you are not? Is there anything you can learn from that person?