Meaning of software life

    Today, the methods of architecture, design and organization of the software development process multiply like rabbits on steroids. Frameworks, components and libraries are not far behind. Many decisions are based on experience, intuition, or a series of trial and error. With the complexity of the systems, the risks of choosing the wrong tools are only growing. I would like to discuss one of the possible ways to assess the adequacy of tools to the task.

    Everyone finds the meaning of life for himself. Physicists can say that the meaning of life is in the fight against entropy: the transformation of chaos into order.
    In this case, the meaning of software is to eliminate the routine in order to make the creation of order more effective and interesting.

    The text will be long. If you are in no hurry and are comfortable in the chair, then let's try to substantiate this statement.

    In software engineering, developers strive to hide the repeating steps and details of operations behind interfaces, in components, modules, services or controls, to separate the implementation of the solution of a problem from its formulation / interface.

    How well the component or program fits the user's task can be judged by the number of trivial, routine steps which the program allowed to avoid and how many new ones it added. Also a plus is how much less the user must now go into the details of the task, and a minus - how much extra effort should be put to study the program in order to start using it effectively and solve the technical problems it has brought in.

    The basic element in program design is the separation of functionality and its implementation. Like many other things in life, this raises 3 major questions:
    1. What do we want to do?
    2. How do we want to do this?
    3. Why do we want to do this?

    The first is a question for a functional specification. The second is the technical implementation of a specific functional. But the last question, why we are doing this and why we need it, defines the general direction within the framework of a broader task and directs our choice among possible answers to the questions “what” and “how”.

    Software design often gives high-quality answers to the questions “what” and “how”, even if we go down to the smallest details:
    - What transparency should the shadow have for this button?
    - How to send these 2 bytes to the server?

    On the contrary, the answer to the question “why” is often given at the level of the entire program and large parts of functionality or architectural solutions, but for smaller details it becomes too unreasonable to ponder and justify each decision. Accordingly, it becomes difficult to justify why “solution A” is better than “solution B” in the framework of task “C”.

    The choice of non-optimal tools and solutions can be quite destructive, leading to the effect of a chain reaction when the attention of designers and developers shifts from the organization of ideal interaction with the user to the fight against technical problems in adapting the chosen tools to the existing task. The project requires more work, and the enthusiasm of developers falls, threatening the quality of the final result.

    How to evaluate the quality of such solutions? One of the good options is to analyze routine steps and compare solutions after dividing the task into two parts: repetitive / boring / auxiliary / mechanical and creative / interesting / important / functional.

    Routine identification shows
    - Where and how the program can be improved.
    - Do we use the right tools to do the job.
    - Can we increase the creative part both in the work of programmers and end users.

    Let's take a couple of scenarios and see how you can use routine analysis to improve user interaction with the program. For illustrative purposes, the examples will be based on the interaction of the end user with the software, but the final principles can be applied to components or frameworks. The problems of users and programmers are largely similar, especially when judged by WTFs / minute

    Example one: saving a file in MS Word

    Most users have worked with Word. The dialog for saving a document, especially for the first time, can seriously puzzle:

    - Have I chosen the correct file type?
    - Do I need to fill out all the tags, enter a name and a subject, or only a part of these fields?
    - What is the difference between a title and a theme?
    - Do I have to specify the encoding? I remember I had problems with incorrect encoding before, so this should be important.
    - Where to save the file? I have my articles on a shared disk, entries in My Documents, corporate files on a network resource, project documentation in the project folder, etc. Maybe just save the file to any temporary folder and decide later?
    - Why the file is now called by the first line of text, and the window title was “Document 1”; is it a bug or feature?

    Over time, you become accustomed to this dialogue and know which parameters to enter and which to ignore. All that remains is the question of whether all these parameters are necessary.

    What the user needs is to "set the name of the text and make sure that I can find it the next time I want to work with it." The task does not include determining the folder to save the file or choosing the correct encoding. In fact, even saving the file is not included: all that the user wants is to make sure that he can find his text next time and do something with it: print it, continue working or send it to someone by mail.

    Can I save a file differently? For example, some people are happy to use draft drafts of Gmail letters to prepare texts with simple formatting. Gmail does not bother the user with questions about when and how to save the document - this is done automatically. You can enter a topic, but even this is optional.

    Looking at how GMail managed to remove all routine actions and make saving documents completely transparent for the user, could the same thing be done in MS Word? Of course:

    - Define a standard location for saving new documents
    - Name and save a document automatically
    - Give the user the ability to rename and move documents

    As a result, the user is no longer distracted by technical details:

    - The user gives the file a name when it needs it, and not when the application needs it.
    - The user does not need to decide when the file is copied from memory to the hard drive.
    - The technical parameters associated with the save dialog box can either be removed or transferred to the less commonly used export dialog, so the user no longer needs to study them for everyday use of the application.

    It’s just wonderful when you can concentrate on your work without being distracted by extraneous things.

    Of course, Word is a large and complex program that you can customize for yourself. You can even write a VBA script to do "save as in Gmail". But for this you will have to pay time to study and go into technical details that are completely uninteresting to the author writing a novel or to a cook filling out his recipes. Yes, and the programmer ... I don’t know about you, but I, for example, had the reflex of periodic pressing Ctrl + S worked out much earlier than I learned about autosave in Word.

    Second example: rainy day

    Мне надо не забыть зонтик, если планируется дождь, для чего я использую гаджет прогноза погоды на странице iGoogle.

    По шагам процесс такой:

    1. Проверить с утра iGoogle
    2. Нажать на ссылку детального прогноза, посмотреть в какие часы ожидается дождь
    3. Сравнить с планом на день и решить, брать зонт или нет
    4. Не забыть про зонт, когда буду выходить

    Каждый шаг занимает некоторое время, требует немного внимания и предоставляет возможность ошибиться. Если дождь шел рано утром, но теперь ясно, и зонтик больше не нужен, я могу не заметить, что дождь снова собирается идти после 6 вечера. Я могу отвлечься на завтрак и не проверить информацию о погоде, или же проверить все как надо, решить что зонтик нужен, а потом забыть о нем, через полчаса, выходя из дома.

    Since the task literally stands as “not to forget the umbrella, leaving home if there is a chance to get in the rain”, then close to ideal it would be to hang an inexpensive tablet with a program on the inside door that will check the hourly forecast, compare it with my schedule and say something like: "Take an umbrella if you are on the street after 6 pm."

    I don’t need a cool application with the ability to compare the current weather with the average annual statistics in Tahiti, but only a reminder “today it will pour like a bucket” and only when necessary. You can, of course, force your wife or girlfriend to do the same, but this is not a solution, but cheating, so back to the solution with the tablet.

    All the risks are now left in a single step - look at the tablet before leaving the house.

    If there is no tablet, you can use a smartphone. The difference will be in determining when to turn on the reminder. The ideal time is “just before leaving the house”, but in my case it’s also suitable “when the charger is disconnected”, since this also happens right before leaving.

    Interestingly, by removing unnecessary steps and risks, we, as developers, not only made the user's life easier, but we ourselves can focus more on the further improvement of functionality.


    The above examples can be used to create “security questions” to assess the usability of the program.

    - What is the real task of the user if we eliminate all the technical elements introduced by the program?
    - Are there repeated steps in the task; were they fully or partially automated?
    - Are there purely technical steps introduced by the program; can they be hidden from the user?
    - Are there any optional steps that distract the user's attention?
    - Does the program require decisions that are not directly related to the user's task?
    - Does the program require making decisions “out of context” when the user does not have the necessary information to make a decision?
    - Does the user have to make related decisions separated by large periods of time?

    Such questions are useful in themselves, but they are based on one basic question:

    - What part of the work (when using the program) is characterized as repetitive, boring, optional and mechanical, and which remains creative, interesting and important?

    In the absence of a better term, I call the first part a “routine." "Routine" is that part of the work that can be automated, eliminated or hidden.

    The rest of this, in fact, is the real work - its important and / or creative component. This is the part that requires the user to make the necessary decisions and the task of software to remove all boring, routine elements from it.

    Also popular now: