How to clean the onions, or why software development is out of control

You have invented a startup and with the best intentions are hiring a developer to implement your idea. But it's week after week, and the app still needs some work. Somehow new functions appear imperceptibly, and the scale of the task is gradually expanding.

One gets the feeling that the project has healed with its own life and is trying to devour you.
')


How did this happen? Maybe hired a bad developer? Someone was wrong in the planning of the project? What if the idea of ​​the project itself was terrible?

Maybe. But often the project is doomed from the very beginning to failure due to a misunderstanding of one important point.

We assume that a product is determined by a set of functions written on a piece of paper: sometimes something is added, sometimes it is removed - but the scale of the project can always be understood at a glance.

This assumption is incorrect .

A project is not a sheet of paper, not a two-dimensional object — it has depth .

Each function on the surface can be expanded - and so on, layer by layer. If I have a tendency to loud headlines, I would say that every application is a bow , and you need to know how to clean it properly. Not very clear? Then let me explain what I mean, and tell you why it’s impossible to open application layers without tears.

Transferred to Alconost

Our library is the killer of all libraries.

Consider a specific example. Give me an idea.

Often, readers need a book that is not in the nearest library - but it may be someone else nearby. Let's make the same application, in which some people will send requests for books, and those who have such books will respond. And from each operation we will take a percentage.

Brilliant.

I know I already talked about this. So, the functionality is quite simple:



You can send TK to the developer and start thinking about what to call our startup killer: kaBooki? lib.rari.ly? reddit?

Well, let's go. Let's take a closer look. (And by the way, “reddit” is already taken.)

Let's ask a couple of questions about the application and see where it takes us.

How do users pay each other? Do they just give each other cash when they meet or pay for books through the app?

They must pay by card through the application - so we can withdraw a commission.

How is the book requested? In a sense, what exactly is the user doing in the application? Fills an open form with the name of the book and the name of the author?

Hmm ... Perhaps the user is looking for a book in the application and selects the right one.

Well, that means we need a database of books.

Well yes.

And what, in fact, is the application for the book? Maybe sellers see a list of all requested books? Or do we send notifications to sellers - such as Uber or Thumbtack?

Like Uber: we send bids to those who have the right book.

So sellers have to put in the application all the books put up for sale?

Yeah.

How is the transfer of the book? Do users send them themselves? Or do we deliver?

Delivery is our concern.

So, you need a system that will tell you which books and where to pick them up, and where they need to be delivered. I guess drivers will want to see the shortest route between these two points, right?

Okay, do without delivery. Let users send books by mail.

So we will show the sender's address to the sender? What will we do with shipping costs?

Generally speaking, let's do this better: the buyer and the seller should live side by side. Then you can just go and pick up a book - and even make a new friend, great?

So, you need to select users who are nearby. How will they find each other? The application will be updated in real time map, with which you can schedule a meeting?

Okay, so be it. No difference.

We set the price - or users agree themselves?

They will negotiate the price themselves.

How will they do it? Will the app have a built-in chat?

They can just call each other.

Clear. So do we need to confirm numbers by SMS? What about ... well, I think you already understood. I can go on forever.

No, please.

Let's see what the list of functions looks like now:



And each item can be opened several more times. But we just removed the first layer of our onion - and this is what happened.

Hush, hush, do not cry.

So what happened?

First of all, let us clarify what is not the cause of such an expansion of the functional.

Pile up unnecessary functionality? Not.

This is the case when new features are added to the product. If you look at the final list of functions, we will see that each item is needed for the work of the original idea.

Technical implementation issues? Also no.

We did not choose a suitable architecture for the chat system and did not look for a payment platform that would be easiest to implement.

It's not about that. A good developer will talk about a variety of technical options for implementation - but he will not be able to decide which functions you need.

Marketing considerations? Past

We don’t wonder if someone will need such a product, don’t ask what will make the first users pay for the subscription when there are very few other users, and don’t think whether users will be willing to pay for such a service.

These questions are related to the verification of the idea , the definition of the market niche of the product and pricing strategy . And these, of course, are important questions. But they are not the reason for the proliferation of the list of functions.

Yeah, and global warming and Baba Yaga have nothing to do with it either. Maybe call the cause of the problems with this your "bow" or we will go through all that is not the cause?

Ay, you are bored. Okay. I explain what happened.

We have completely misunderstood how things are going with the complexity of the software.

We expected that the complexity of a separate function is represented by its description. Well, the truth is: to write code or whatever programmers do there, it may take time, but a specific function can still be described with a couple of words. "User makes X using Y". So?

Not.

The software functionality is more like fractals.

The closer you look, the more details appear.

Is the onion a fractal?

Nah, we now have another metaphor.

We started with a general idea of ​​what functionality is needed. But developing and using an application is a look from a much smaller distance. We explore the application step by step, and new tasks may arise at every step. To solve them, you may need to rework a specific step, add new steps and even completely new features.

Imagine that you are planning a route from home to work. On the map, the route may look like a straight line.



But if you increase the map, it turns out that the straight line does not fit into the grid of city streets: on the route there will be public transport stops, ups and downs, various obstacles. If you go to work on foot, the route will be one, if you go by bicycle - the other, by car - the third.

Software development is in many ways similar: the closer you look, the more details are needed to solve the problem.

Fine. Paint everything completely to the smallest detail. That is what I needed. But ... so, probably, my product will never be published?

In short, yes and no. The complexity increases because we start with a description of the function, which usually represents the goal of the project, and then we go down a level and try to implement every step necessary to achieve this goal. The more we delve, the more difficult it becomes to understand the function.

However, complexity in itself is not a problem. The problem comes when we decide how this complexity will be revealed. We pass the description of the functionality to the developer. After a few weeks, we have the first version of the application, and we check it: we go through the application step by step and notice huge holes in the functionality. We write down the comments, send them to the developer and wait for version number two.



In the end, by repeating it all several times, we get a pretty good solution. The only trouble is that such development is very long: each cycle takes weeks and even months.

It will be necessary to reveal the complexity of the problem solved by the application in any case.

But playing the “hot potato” with the developer, repeatedly transferring the application from refinement to checking functionality and thus revealing its complexity, is expensive and time consuming.

And you need to do this:



We need to uncover the complexity as far as possible before the code begins to be written. Removing it layer by layer, we should make the most elaborate and exhaustive list of functions - and I would like to do it quickly and inexpensively.

The solution is to drive along the revision cycle not an application, but a technical task.

We need to switch from this model:



To this:



In order for the work to be effective, we need, first, to somehow compile a list of functions so that we can work with it. And secondly - to figure out how this list of functions can be effectively investigated.

Here we will talk about it now.

Operation scheme

We will have to stop thinking about the application from a business point of view and start thinking like a user - at this level we will be able to deal with the complexity of the software.

First, make a list of user goals : why users will go into the application?

Then plan a sequence of user actions , step by step going through and recording all the steps necessary to achieve the goal.

So you make a scheme by which users will act in the application.

This is done in many different ways. You can simply schematically depict each step. You can draw screen layouts along which the user moves. You can draw a flowchart - on paper or in any application.


An example of a simple layout (source)

Whichever option you choose, try so that it does not slow down the work: if you do not own the graphic editor as “excellent”, it’s better to pick up a pencil and paper.

Each application screen should be represented on the diagram. For example, if at some step there are several screens, break this step: we need as many details as possible.

As you do the above, the complexity of the application will be partially revealed. But we will go even further.

Ask about everything

Asking questions, as we did a little earlier, is almost endless. True, it is difficult to figure out where to start.

But do not despair: I have compiled a list of common questions that apply to most software. They fall into four large categories that you can navigate by developing your own scheme.

Carefully review all the steps on your scheme and for each of them ask the questions listed in the list. If the answer to the question reveals new steps - add them to the scheme.

Next - a list of questions.

User Input

These questions relate to information that the user sends to the product.

• What data does the user enter?
  
• Is data entry free or interactive?
  
• Examples of free input: selection of images for download, video recording, free text input.
  
• Examples of interactive input: entering text into the search field, displaying results from which to choose, choosing an address on a map, choosing from a predetermined set of options.
  
• Can the input be incorrect? What should the application do in this case?
  
• Is passive data being used? The most common example is the user's GPS location.
  

What information does the product need from a new user ? Can the user change them later?

Information displayed to the user

If we talked above about data entry, now consider the output.

• What data is shown to the user on a specific screen?
  
• How are they displayed? Examples: text, images, maps, lists, diagrams.
  
• Do I need to sort the data in any way? Examples: by novelty, distance from user, relevance.
  
• Does the application use active outgoing data transfer? Examples: emails, push notifications, SMS messages.
  

Interaction between components

These questions relate to how different components of a project (users, product, other services) interact with each other.

• Do users interact with each other? Examples: exchange messages, add to friends, “like” or tag other users ’materials.
  
• Do users interact with external services? Examples: payment services, tracking parcels, input through social. network.
  
• Does the product interact with external services? Examples: location search services, weather forecast API, social networks (“Your friend X has joined us! Look at the page!”).
  

Functionality for a business owner

Questions about what you as a business owner need from a product.

• Do you need to receive alerts or summaries via email or other means of transmission?
  
• Do you need a separate system for you or your employees? Examples: driver application for delivery service, real-time order management interface for kitchen personnel.
  
• Do I need an interface for manual approval of users or their materials?
  
• Do I need a material moderation system? With it, administrators can easily delete user posts, disable their user accounts, etc.
  

Somehow ... a lot of questions.

Exactly! And these are the most common questions that are often forgotten at the beginning of the project. For each individual product as you work on it, many other more specific issues will appear.

Putting it all together

Building a diagram, asking and answering them will help you understand what you are missing. Repeat it all a few times - and you should have an impressive list of functions for which you will feel much more confident.

I was hoping that you had some tricky trick to help get my project out. And over all of this seems to have to work hard.

Of course. But at some stage "this is all" one way or another will have to do.

Do not forget why we even started to do this: the software functions conceal an unobvious complexity, which in any case will have to be revealed - you can only choose when to start cleaning this “onion”.

In fact, there are two options:

1. You can clarify the goals of users, build a layout or a flowchart, ask lots of questions about their own assumptions and “strip” our bulb, as we did a little higher. But there is, of course, another option.
   
2. You can immediately put before the developer the task of making the application, and then with each new version gradually reveal all these nuances - one week for each "layer". So for a few months you will learn everything that could be understood in a week of working with a pencil and paper.
   

Now you understand why software development projects sometimes turn into monsters who are trying to devour their owner alive.

So go ahead - explore the functionality of your project: build schemes, voice your assumptions and ask questions about them. So you can quickly and inexpensively reveal the bulk of the upcoming tasks.

Rid yourself of unnecessary worries and anguish, release your project into the world - and let it flourish.


Alconost is hiring

The article is translated in Alconost.

We at Alconost in the Minsk office to work on the Nitro project (professional live online translation service) need a cool Frontend developer (React.js). Send a story about yourself and examples of what you did before to dev@alconost.com

Alconost is engaged in the localization of games , applications and sites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com