Kennis Blogs Software Development - More than just writing code

Software Development - More than just writing code

Imagine being approached by a customer who asks you to develop a piece of software. You listen to their idea, some code is written and then you're done, right? This is how many non-techies view the process of software development. In an ideal world - where customers know exactly what they want, needs and requirements never change and cyber-attacks are non-existent - this would be true. Unsurprisingly though, the reality is different. There is much more to software development than people think. This is especially true if you're looking to develop safe, reliable, maintainable and future-proof software. In this blog, I'll discuss my vision on the topic and give you a picture of what I mean by high-quality software development.


1. Thinking along with the customer

Looking at our software development customers at Avisi, we almost always see one of the following two scenarios:

  1. The customer is enthusiastic about his new idea! He has thought of a way to improve the way he serves his customers or how his team can work more efficiently. It requires software and the question is: can Avisi develop this?
  2. We're already working with a customer and we see opportunities for software that can improve their business results.

As a software engineer, I look at both scenarios and think: cool, helping a customer by developing software! This thought is immediately followed by all the necessary steps that must be taken to achieve the best result. Are we sure that we have all the information we need to solve this business challenge? Will this software still be valuable in the future? What does the market look like now and how will this change in the future? These questions are difficult to answer but are very important for predicting the success of software. As experts in software development, it is our job to think along with our customers because only then can we add value or solve a problem!


2. Divide Software Development Projects into different phases!

A software project is only successful if the delivered software meets expectations. I recommend dividing a project into small, manageable pieces to ensure that corrections can be made along the way. I do this by dividing a software project into the following steps:

  1. Software requirements analysis
  2. Proof of Concept
  3. Minimal viable product
  4. Further development


2.1. Software requirements analysis

It is crucial to carefully think about the software that needs to be developed. In my opinion, it is better to not build any software than software that has not been thought through properly. Without a clear vision, you will usually see that the software ultimately does not meet expectations or cannot grow with the organization or changing market conditions. This will inevitably mean you'll have to start from scratch. Believe me, you don't want that. It is much more cost-efficient to invest the time needed in advance to find out all the minimum requirements that the software must meet. It's important to call upon the help of professionals who know what the possibilities and impossibilities are in the field of software development. I am a big fan of a software requirements workshop, an interactive workshop where all stakeholders come together to discuss and determine the software needs together. This efficient approach gives a clear picture of where you want to go with the software in just 1 or 2 days.


2.2. Proof of Concept

Having a clear picture of the needs and functionalities does not mean you can hit the ground running and start building software. In my opinion anyway. Before I start developing the final product, I want to prove that the ideas that were acquired during the software requirements workshop are feasible and will provide added value. One way of doing this is by making a Proof of Concept. A Proof of Concept is a working piece of software that demonstrates the software solution. In addition, building a piece of software will give you insight into the technical feasibility and possible risks of the project. It also helps in estimating the amount of time and investment needed to realize the project. In short, a Proof of Concept increases the chance of success of the final software.


2.3. Minimal viable product

How long would it take to develop software with all the possible functionalities you would like to see in your final product? Though this can work great for small projects, I don't recommend it for larger projects. You will spend years developing the software before it can be used. During this time, needs will change due to changing circumstances and you will end up unhappy with the final product. This can be prevented by building a minimal set of functionalities that you can use to launch the software, also known as a minimal viable product (MVP). By starting with an MVP, you can deploy the software faster and learn from actual user findings for the further development of the software.


2.4. Continuous development

After your MVP is released, you can zoom in on the delivered software. Does it work well? Are there things that you would like to do differently? Which functionalities could have even more added value? This analysis will provide you with the insight you need to continue developing your software. It's also important to be aware of the fact that software will never be finished. Circumstances are forever changing and your software will need to be able to move with it. By being proactive, you can avoid unnecessary costs.


3. Quality

Creating software that works isn't an art. All you need is a basic knowledge of programming and you will probably be able to create something that works. Making sure that software is always available, reliable, safe, scalable and well-performing is a lot more complicated. Practise makes perfect and in time you can develop a standard approach to guarantee the quality of your software. What is important when it comes to high-quality software? Here's a list of a few essential factors:


3.1. Security first

The media loves headlines like: "Company x has been hacked and personal details have been leaked" or "University Y has been taken hostage by ransomware". Security risks are a hot topic. It's impossible to be totally risk-free as criminals are very inventive. In my opinion, a software development company must avoid as many risks as possible and make life hard for these cybercriminals. That is why security specialists are of vital importance in any software development company. At Avisi, we collaborate with our security specialists to set up processes that guarantee security (we are proud of our ISO27001 certification!). In addition, we test all our software automatically and manually for possible security issues.


3.2. Code reviews

Believe it or not, even software developers are human: we make mistakes and can overlook things. Also, the way the code is written should be consistent in a project. This only works if someone else checks and reviews your code. Code reviews make it easier to find bugs, make the code easier to maintain and scalable and it ensures that developers learn from each other. In my opinion, you cannot build quality software without code reviews, unless you have a team full of super-geniuses. I have never seen this yet but perhaps it was because I was part of these teams myself...


3.3. Version management

Great software isn't static. What might work today could be useless in the future. The dynamic nature of software as it continues to develop makes it necessary to implement version management. This helps software teams to keep track of all changes made to the code. It makes it easier to deal with bugs as you can reproduce the bug faster and fix it, or, rollback to an earlier version of the software.


3.4. Test-Driven Development (TDD) or Behavior-Driven Development (BDD)

Not so long ago, software developers would write a piece of code and then toss it to testers. The testers would do their job and come back with the bad news: this is not what the customer wants in terms of functionality and it contains 213 bugs. This is not an efficient way of working. You have to embed testing in the entire development process by writing test scenarios and creating automated tests before starting on writing code. If you do this, your code can be continuously tested against the requested functionality and bugs can be traced and solved much easier. This might make the start-up costs of a project somewhat higher, but you'll thank me in the end!

TDD and BDD are software development methods in which testing plays a central role. If we're testing the behavior of an application, we go for BDD. If we're testing software integration, then we use TDD. In my opinion, it doesn't matter which method you use. Just make sure that testing is important from the start of every software development process. This prevents unnecessary costs and frustrations.


4. It's all about ... teams!

Your processes have been optimized, the software requirements are clear, so the next step is ... developing the software. But how do you put together the best team for a specific project? When I assemble teams, I make sure there's a match between customer, project and team members. If a customer is very opinionated but lacks the technical knowledge to oversee all the consequences of certain decisions, I ensure that the team is made up of members that can handle this and know how to be persuasive in their communication. Or if the project requires a lot of innovation, I put together a team of people who like to embrace new technologies and processes. The basis of putting together the best teams is making sure that I know the people I work with well. Using additional tooling, like Alva Labs, provides an extra dimension. This tool gives me insight into the way how everyone's personality affects team dynamics. It allows me to plot different teams together until I find the ideal mix.


5. Knowledge sharing

The rapid developments in the field of software development make it nearly impossible for an individual to keep track of it all. Luckily, this is not necessary. At Avisi, knowledge sharing is encouraged throughout the company. And this knowledge sharing doesn't just mean sharing with your own project team members, but also across projects and with the rest of the organization through weekly show-and-tells, monthly Techdays and writing blogs. My advice: choose your own form of knowledge sharing, the most important thing is that you share knowledge and absorb it.


6. The future - innovation

I have mentioned it before, but I want to emphasize it again: software development is forever changing and dynamic. Just think: 20 years ago, we installed all the software on our computer, now we do everything in the cloud. It's 2020 and artificial intelligence is seen as the holy grail, but what will be the next best thing in 10 years? Nobody knows. What we do know is that the world has changed and the way we use software has changed even faster. My advice? Make sure you are ready for innovation. It not only makes your work more fun, but it also increases your chance of success!