Task compression method

    Hello, Habr!

    We programmers love to keep everything in mind. But sometimes so big tasks arise that they simply do not fit into the skull. I will talk about a method for compressing such tasks in this article.

    There will be many screenshots and a little surprise at the end.

    First, I’ll introduce you to the course. I am working on Pintask, a programmable task tracker . And, of course, it has the ability to invite users. Until recently, it was implemented as an invitation email, in which a special token is wired. And everything was fine until a once invited user tried to register in Pintask independently, without token .

    It would be right to let the user go, because emails are the same. But the system decided that it was an attempt to register to an existing address, and refused the user. Confused, he wrote to tech support: “Guys, I’m registering for the first time, but the message says that such an email is already registered . We resolved the situation manually, and then sat down to think how to avoid this in the future.

    The first thing that came to mind: to abandon token and allow to register at an existing address (if there is an invitation). “Wow-wow, take it easy” - grinned Vanya, another programmer on the project, and sent a screenshot of his email client. It was visible on it that one client checks 5 different mailboxes: one for work, another for personal correspondence, and three more “special purpose” mailboxes. It became clear that the invitation can come to the work address, and the user can register through a personal one.

    Wait, wait ... what if the user is already logged in through a personal address and colleague just sent an invitation to a working email? “Everything is more amazing and more amazing,” Alice would say if she had found herself in our room then. And, perhaps, she would agree that in this case, it would be necessary to display a proposal to combine accounts. However, we did not have full confidence.


    When we realized that possible cases breed like a cell mass, we decided to apply the method of task compression by the principle of untangling wires. Everyone knows: to lay the wires compactly, it is enough to pull out of the ball one at a time and put in a box.

    A board with lists acted as a box, and characteristics of the current state as wires. It turned out that there are only four of them. Finally, we sighed calmly.


    Then it was necessary to understand what actions are possible on the part of the service. It turned out that three normal reactions and one exception are acceptable, that is, four again. And it was good - the degrees of two are generally reassuring, and two fours in a row finally enter into a trance.


    Then began the most interesting . Using the reflections of the cards, we compiled a matrix of all possible cases (in the screenshot: 3 of 16) .


    Since each characteristic turned out to be binary (“there is a token - there is no token”), we used binary notation in the list headers for ease of perception. If one of your characteristics takes more than two values, it's okay - just use a number system with a different base.

    As a result, we have created fertile ground for thought. We decided to fix what should be done in each case, and again applied the white magic of reflections.


    In my opinion, the most difficult part in designing is to consider all cases. So, this scheme gave confidence in 100% coverage of possible options. At the same time, she facilitated acceptance testing and allowed to cope with the task in a couple of days.

    In conclusion, I present to you a public board with the final result.

    PS One of the characteristics turned out to be superfluous. Special Audience Award for those who find it :)

    Also popular now: