Written by Thom Lamb
Signals of Quality Software Development
Jun 23, 2020 · 7 min read
An in-house development team is not the best fit for every business. Hiring an external firm to provide their technical expertise is a common practice in every industry due to the importance of software to day-to-day business operations in today’s world. Software development doesn’t have a certification body for developers, so it’s difficult to know how well trained and effective a developer or team of developers is without having a background in development.
This leaves many business leaders with a difficult question:
“How do I know that I’m getting my money’s worth from my developers without having to get a computer science degree myself?”
The goal of this article is to talk about some best practices that we have developed here at Quantum Mob in order to build industry worthy software.
There are certainly a lot of ways to build software and this is not an attempt to criticize other's process. We simply want to explain, to the non technical user, some examples of less than ideal software that can cause major problems for you. This is based on projects that we have rescued from other developers in the past.
Our hope is that you can learn how to differentiate from good and bad process, and learn a little bit more about how good software is built, so that you have the confidence when you are talking with potential developers to know the right questions to ask to find the right fit for yourself and your business.
If you understand the why and the how of these concepts and processes, you will be able to interview developers and understand what you can expect from them. More importantly you will know if you are going to end up satisfied with the work they do.
Finally this is not meant to be an exhaustive list of all aspects of software engineering. We have chosen to narrow our focus to those subjects where we see the biggest impact in the end product, and therefore the best source of Signals in Quality Software Development.
The key elements we are going to focus on in this article are as follows:
Section 1 - Development Methodology: Product Road Map, User Stories and Client Feature Demos.
"Art is never finished, only abandoned." - Da Vinci
Any good software development methodology will aim to take a large complex project and turn it into something more granular, more consistent and more predictable. One way to divide and conquer this complexity is by breaking the project up into Features that are scheduled on a Product Road Map. This can allow parts of your application to be completed first, perhaps allowing you to begin using the software before all features are completed. At the very least this gives you the assurance that things are on schedule.
In order to organize the building of Features (sometimes called Epics) we break them up into smaller atomic pieces that individual developers can work on and complete in a short period of time. This allows many developers to work together, and also allows the company to evaluate the work on an individual basis. These pieces are usually called User Stories.
Once all the User Stories of a particular Feature are completed, it is a good practice to demonstrate the new feature to the client. At Quantum Mob, we aim to do this bi-weekly.
Benefits of following a process like this are listed below:
Incremental Delivery of the Product.
More granular Feedback on the product.
Better delivery schedules.
Client starts to learn how long new features will take.
Some developers will argue that “all this process” would take extra time and effort and increase cost. This is usually an excuse to avoid the accountability that comes with routinely reporting on progress, instead of simply promising to deliver the entire project at once.
Consequences of not following this or a similar approach are:
Unpredictable delivery times.
Not knowing how to do User Acceptance Testing.
Not understanding what you are being charged for.
Section 2 - Quality Assurance: Source Control, Code Reviews and Testing.
Source Control and Code Reviews: As developers complete User Stories, it is considered a good practice to request a Code Review (more commonly known as a Pull Request in developer parlance) of their work from a colleague. In order to make this process possible, good developer teams will use something called Source Control.
Source control means that all your code is stored on the cloud in what is called a Repository. Developers can connect to this repo, copy it, and make their own updates. These updates are then pushed and submitted for a review. Once the review is accepted, the changes are merged into the main Repository. This also allows us to go back and remove updates if we need to, and it also allows many developers to work on the same code, and not interfere with each other.
Git, Mercurial and Subversion are commonly used versions of source control.
Benefits of Source Control and Code Reviews:
Shows Due Diligence in holding developers accountable to quality code.
Makes code modular, so it’s easier to change and undo if a particular Pull Request causes problems.
Ensures there are multiple copies of the code, and a detailed history of changes, and that you as the client have access to the code from day one.
If your developers don’t have a solution in place for source control then there is no way to easily do any of this. It can also make it very difficult for you to gain ownership of your code, in case you decide you want to hire your own team and take over for example.
Testing and Quality Assurance: The best way to avoid your software breaking in the hands of your users is to break it in your own. Good developers will implement a combination of manual and automated tests for common issues to head them off before they can become a problem.
Quality Assurance: Having an independent function to confirm that User Stories are properly completed can be important as the size of your developer team grows. This function is known as Quality Assurance. Here at Quantum Mob, we use a dedicated Quality Assurance person on many of our ongoing projects, and we have noticed that even with a fairly small team size, this Assurance can lead to more productive developers and fewer bugs.
Testing: We leverage automated testing that we run every time we are about to merge code into the code base. This allows us to ensure that the database, the business logic and the front end code haven’t been broken by the new code. This is called Regression Testing.
We also test for Performance and Accessibility using a tool from Google called Lighthouse. This testing allows us to diagnose things like how long does it take your application to load and become interactive. It ensures that we are using best practices in application development which can have major implications to SEO.
We also test the internals of the code to make sure that each piece of code is doing what it is supposed to. This is called Unit Testing. Unit tests are code that automatically confirms that the User Story is properly built.
There are a number of other things we do to test our application, but these are arguably the most important ones to the end client.
Benefits of Testing:
Can prevent bad code from entering the code base.
Ensures Good SEO.
Ensures Features work as expected.
Tests act as a foundation for documenting the code, since they show precisely what the expected behaviour of sections of code are, and how they integrate and work together. This allows new developers to read the tests too quickly understand how the application works.
Ask your potential developers what kinds of testing they use. Testing is a very controversial topic and very talented developers can have very different opinions. The only constant is that there should be some thought given to testing.
Section 3 - Architecture:
Good architecture in the design of your application is essential. Understanding what the application will be asked to do today and tomorrow can inform how the data, business logic and user experience should work and be structured. A common mistake we’ve seen in many projects is over-engineering a solution, adding functionality that is not needed for the task at hand. This means you are paying for things you don’t currently need. Solutions should be right-sized, but with a plan of attack for how to increase performance and scale as demand increases.
Architecture should also involve a survey of common application functions like push notifications, user profile management and invoicing to name a few. These functions are available from third party providers. If your development team is recommending you should build a product catalogue or user profile from scratch, they should have a compelling reason why.
Good questions to ask your development team are:
Can I see the diagrams that describe the pieces of the application and how they work together. What are some alternatives to this architecture that you have considered and why did you make these choices instead.
Are there any changes we will need to make if we increase users 100 X. What would that look like architecturally.
What is the first thing you would recommend improving if we had extra budget ? (This is a good question to discover over engineering).
Are you, and how are you leveraging third party software. For what benefits ? (Contentful for Content, Firebase for basic application function, Intercom for messaging, there are lots of APIs)
Are there any in-house applications or modules that you plan on using to speed things up or make them more scalable ?
How is the database structured, why is it best to structure it this way ?
What concerns are being handled on the back-end and what things are being managed on the web or mobile front-end.
Failure to have thought about these concerns can have the following impact:
Software is far over budget and over complicated.
The developers use a “template” that is another application that they built, and they are just changing parts of it. This can mean the code will be confusing to work with and that a lot of features will be hard to use. Usually if this is something that the developer is planning to do, but they don’t want to tell you, then they will not want to expose their process bc that will make it obvious. There are so many problems with this we are working on a whole other article about it.
Where do you go from here?
Hopefully, through this article, you’ve confirmed that your current development team is up-to-date with best practices. If instead, the above is raising red flags or you’re worried about if you’re being treated fairly by your development team, you can reach out to the authors directly at firstname.lastname@example.org, or to another developer that you trust to conduct an audit of what’s going on behind the scenes.