Guidelines for creating quality business software.
The guidelines in this article are focused on creating high quality business applications, but they probably apply to any kind of software development.
What is good software?
The first question to make, when talking about better software development, is “what is good software”? What do we want to achieve? The following are the main properties of good software development:
- It solves a (business) problem the client has/had.
- It is reliable.
- It is user friendly.
- It is maintainable.
- It has adequate performance.
- It is testable and tested.
- It is documented.
Each of the above properties deserves an elaborated explanation of its own. In the future I will elaborate on each property in detail. For now, this is our base for writing of good software.
Planning and design
Failing to plan, is planning to fail.
Every project with the slightest complexity needs upfront planning and design.
First we need to have clear what the goal is for our software project. What is it that we want to achieve? What problem will it solve and for whom? Who are the end-users? Who are the stakeholders?
Next we need to identity the steps we need to execute to reach our written goal.
In time of Agile development, people tend to forget that planning and design is still the key to successful software development. Leaving out planning and design is like driving a car at top speed, without knowing where to go to. Agile only changes the way of planning and design, but not excludes it. Go and read the Agile principles, it talks about requirements, design and architecture.
My advice is to stop and think well before doing anything else.
In general there are two main design documents that are made upfront.
- Functional design
- Technical desgin
Functional Design
This contains the solution written in a way all stakeholders can understand. This includes, the problem we are going to solve, UI design, target end-users, other stakeholders.
Technical Design
The technical design is intended for development team of the solution. It provides a blueprint how we are going to solve the business problem. The technical design can be done by an architect or by an experienced team of developers.
Change will happen
Planning and design are always essential in my opinion, but we can also be sure that changes will happen along the way. This means that our planning and design also need to change when needed. Always communicate well the changes to all team members, so that everyone stays on the same course.
Domain Driven Design
Core business processes are best captured using Domain Driven Design (DDD). DDD has the following advantages:
- Ubiquitous language. This is a language that both the business experts and software developers understand and use to create the software solution.
- Business experts and software developers sit together and exchange knowledge. The lines of communication are therefore very short.
- DDD is written in pure C# or Java, without depending on external libraries. This makes this code future proof.
- DDD is focused on capturing business logic in software, without concern about the technical implementations, like which database to use.
- Unit tests can confirm the correct working of the code.
Tests
Automated tests are indispensable to create reliable quality software. It is impossible to manual test every little detail of an application after every change you make. Automated test guard against breaking working software and can proof that code is working as intended. If you fix a bug and write a test for this specific bug, you can be sure that this bug will appear again.
There are three types of automated tests:
- Unit tests
- Integration tests
- End-to-end tests
Unit tests, test one specific part of a code. Integration tests, test a compound part of the solution. End-to-end tests, test the whole working of the software, like it is in production.
The base of automated testing are the unit tests. These test will be the mayor part of the automated tests. Integration and end-to-end tests are harder to setup and can not capture all details of the working software. So they are less in number.
Simplicity
Any software project worth doing will be complex. So it is best to keep things as simple as possible. Keeping things as simple as possible will allow you to manage the complicated parts. Break down bigger task in smaller focused tasks. Keep your code readable and clean. Follow SOLID principles. Avoid the urge to include many libraries into your application. Every extra library you include needs study, has its quirks, introduces dependencies, etc.
Communication
Regular communication between the experts, developers and stakeholders is essential.
- Discuss new features and changes.
- Show progress regularly.
- Ask questions. Never assume you understand.
To avoid confusion, recapitulate.
- Use for example email follow-up to summarize what has been discussed.
- Summarize in your own words what you understood the other wants or opinionated.
- End your summary with action-points that surged from the meeting. What, who and when.
Follow best practices
- Follow common best practices.
- Do not invent your own best practices, unless you have good reasons to do so.