Recap In a previous article from the series, we discussed a problem space with some hypothesis that Mark was going to solve by developing a great mobile app. We did it to help Mark to understand what the development process should look like and how to avoid problems Mark had. You can read about the whole situation in Part 1 and Part 2.

 

Solution

In the current article, we discuss a solution space. Whenever you are going to develop an application, you should have in mind that first – you need to address a problem you next are going to solve.

This is a crucial thing in the whole game. When you find a problem, and you know that it’s not only a bunch of your hypothesis but that the problems are real.

There are a lot of practical methodologies like lean startup, and customer development, where you can read about techniques on how to validate your idea. I wish also recommend you the book – “Disciplined Entrepreneurship by Bill Aulet.” In this book, Bill Aulet leads through a whole process from validating a hypothesis up to releasing a product on the market. So you understand the problem you are going to solve, you know that it’s not a hypothesis, but you already collected feedback from the market, and you are sure that hypothesis is right. What’s more – you described it in the form of requirements in your new great app.

So now we need to go to solution space – HOW to answer problems – what kind of solution propose to make users happy.

In software development, a solution is discovered together by a team who develops it later. So this is a mix of different skills involved.

In Mark’s case, he had mockups prepared together with UI/UX designer, and final designs, prepared by a graphic designer. It was a base where developers, after some explanation, started working on a final solution.

Mark’s problem was that he forgot about some essential pieces of the puzzle, and as you can read in the first article from the series, after some time it caused enormous trouble for him.

Business domain understanding

A good understanding of the business domain is one of the first and essential things for developing a great and right solution. The goal is that developers will understand concepts, which are essential in the business domain.

In Mark’s case, it was knowledge of the housekeeping world. How do they work how they are defined, and how do we use them in each stage of the process?

For example:

In most cases, clients are looking for long-term housekeeping services. Most of them are done by people who have no official business registered, so for example, invoices are not required whenever housekeeping services are delivered. Additionally, the business model shouldn’t rely on any payments from users. However, the idea that it relies on a monthly subscription from service providers is a good idea. So good understanding of this how service is offered, performed, and billed is very important to design and deliver a proper solution. If developers understand it deeply, then the proposed solution is better and well-tailored to market needs.

All used concepts and relations between them should be well implemented in software. If it is done right, then it will be much easier to maintain a final product and develop it in the future.

Components of the solution

Every modern software solution is built from many different pieces – we call them software components. For example, a mobile app for IOS and Android is connected through API with a backend. The backend is built from many different components across three business domains. Everything is backed with external APIs for payments, invoicing as well as sending emails and SMS messages.

But these pieces need to be well described to be sure that in the future for new developers and at least everyone in the project, it will be clear to understand without reengineering everything from scratch.

Patterns and good practices for chosen technologies

Patterns and good practices are the next crucial topic. I saw it many times when someone decided to go with technology “A” and developers started working on a project. They were using the same technology, but after some time, you could easily see that every developer was using this technology in a slightly different way. Without let’s call it synchronization. It means that even the same technology can be used differently. You can have the best tools, but if you use them wrong, then you always be in trouble after some time.

If you are not technical I try to explain it even more – let’s imagine that you write 300 pages book in Microsoft Word and you don’t use headers, footers, headlines, but you style everything manually – together with page numbering. In the beginning, it’s straightforward – and it doesn’t matter If you use more advanced features of Word or not. However, when you arrive at 200 pages and you have to change something to page 53 then your whole puzzle collapse. If you use MS Word properly, then it is easy to change anything regenerate your heading, and table of contents and it works like hell. Everyone who has experience knows it, and for me, it’s very strange why in the case of software development in many cases it doesn’t work like this. Developers are building in parallel a very big Word document, and after some time they struggle with any changes. Of course, it’s a simple comparison and software development is much more advanced than operating in Word but more or less this is like this.

Deployment environment, releases

This is the next crucial topic, which is quite often underestimated. When Mark started testing fixes in an application in the same environment where developers were working on new features. This is one of the biggest mistakes which can cause delays in development and introduce many problems. So this is so important to have the order also here. You need in an average project at least three environments. The first one is for heavy testing of increments, one is called staging for testing everything that is going to production, and the last is – the production environment where a fully working solution is deployed. It was also issued in Mark’s case. He was testing features in a solution when in parallel developers were working on some new features. It was very problematic because when Mark was trying to test something, very often it was not working or was already changed by developers. It was a source of frustration for Mark and his team.

Summary

In this article, we discussed a solution space. Problem -> Solution. It’s nothing new, but all the time people have a mess here. The funny thing is that especially in those days people don’t understand how to describe the solution properly. Many people think that the agile approach can replace a solution specification. It doesn’t work like this because it was developed for solving a different issue.

In the next article, we will discuss the remaining pieces of the puzzle – communication flow, project management, change management, and documentation storing.

In this area, Mark also had some troubles, so we will show him how they can be easily solved.