.

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

No alt text provided for this image

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 is a lot of practical methodologies like lean startup, customer development, where you can read about techniques on how to validate your idea. I wish also recommend you a book - "Disciplined Entrepreneurship with Bill Aulet." In this book, Bill Aulet leads through a whole process from validating 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 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 on problems - what kind of solution propose to make users happy.

No alt text provided for this image

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

In Mark's case, he had mockups prepared together with UI/UX designer, 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 series, after some time it caused enormous trouble for him.

No alt text provided for this image

Business domain understanding

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 housekeeping world. How they work how they are defined, how 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, 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 in software components. For example, a mobile app for IOS and Android, connected through API with a backend. Backend built from many different components across three business domains. Everything backed with external APIs for payments, invoicing as well as sending emails and SMS messages.

But these pieces needs 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 a very straightforward and easy - and it doesn't matter If you use more advanced features of word or not. However, when you arrive to 200 pages and you have to change something page 53 then your whole puzzle collapse. If you use MS Word properly, then it is easy to change anything regenerate your heading, table of contents and it works like hell. Everyone who has experience knows it, and for me, it's very strange why in 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 simple comparison and software development is much more advanced that 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. First one for heavy testing of increments, one called staging for testing everything that is going to production and last - 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 parallels 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 develoopers. It was a source of frustration to Mark and his team.

No alt text provided for this image

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.

Tags:

CONTACT US

Do you have a different question?

You did’t find the answer to the question bothering you? Write to us! We can help!

Leaware SA, with its registered office at 86/1 Perkuna, in Warsaw, is the controller of your personal data.

Similar posts

Case Study

Will your startup turn out? How to predict it?

"I have a genius idea! I only need money to development it! "- words that every startuper once said. However, not everything is so easy. To create a truly successful and profitable business, enthusiasm and originality are not enough. It’s important to learn to test all ideas, starting from the product concept, right down to the additional functions. There are many ways to check if your project has a chance to succeed. The most important thing is not to limit yourself to just one method, check them all.

Zbigniew Waz

Android

TESTING AND QUALITY MANAGEMENT. Automatic testing of mobile applications using Xamarin tools

The diversity in parameters of available mobile devices requires software developers to optimise the view of applications for various screen sizes and resolutions. However, this process requires testing the application on different devices, which in turn brings the need of purchasing many devices, as well as separate installation of new versions of the application on different devices or emulators. Obviously, such a traditional method of testing mobile applications leads to numerous problems. In particular, the time needed for conducting tests increases in a linear way depending on the number of devices and along with the development of new versions of applications. In order to solve this problem, Xamarin provides suitable tools, among others, the Test Cloud service, which supports testing mobile applications using a large number of physical devices. The objective of this article is to present selected functions of the Xamarin tools for conducting automatic tests of mobile applications.

Tomasz Soroka

Event

Tomasz Soroka

ASK US

Let's stay in touch!

If you want to know more about how we can help you or you like to be on a current basis, please leave us your e-mail.

Leaware SA, with its registered office at 86/1 Perkuna, in Warsaw, is the controller of your personal data.