DEV Community

loading...
Cover image for 馃 Task analytics as a path to effective implementation

馃 Task analytics as a path to effective implementation

Vic Sh贸stak
Hey! 馃憢 I'm a Software Engineer and founder of a friendly outsource company called True web artisans, with excellent UX/UI knowledge and over 12 years of practical experience.
銉6 min read

Introduction

Hey, DEV people! 馃憢 It's time to share my experience on the topic of task analytics for programmers to execute them as efficiently as possible.

Originally, I was inspired by this article on Habr (in Russian) and thought that I could modify some points from it a bit with my experience.

And here you are reading what I got!

馃摑 Table of contents

Analyzing the task and trying to identify the final needs

We read the task, think about it and try to understand what the programmer ultimately wants to get. It is not always possible to do this immediately, because other people think differently, while programmers often have a "professional deformation", which makes it more difficult to understand what "non-programmer" is thinking.

And here we have only two options:

  • If the task refers to any part of the product being developed, then go there, "click" the buttons and see what happens, re-read the task, check it against what you see on the screen.
  • If the task concerns some new direction or function, or does not concern the developed product at all, then we study the business process. Here the base is the business process.

鈽濓笍 Although the first option also has a business process, but it's not immediately visible.

As a result, the puzzle must come together in your head. I don't know about others (please, share your experience in comments below), but in my head immediately arise possible solutions.

Even without the period of understanding the task as such: if there are options for a solution, then the task is understood and the goal of this stage is achieved!

鈫 Table of contents

Exploring a subject area

This is more complicated and easier at the same time. At this stage, you don't have to think much, you have to research:

  1. First, the business process (in the context of the stage, the business process is the environment in which the task will work).
  2. Then, the software products.
  3. Next, the implementation of existing parts.
  4. And finally, the environment in which the code works and dependencies.

It's important to know the architecture of the application. Especially, if you haven't worked with it before. But anyway, you must see if the architecture has been modified, and if so, what kinds. Over time, the architecture of the application, its external dependencies will always be in your head.

鈽濓笍 This does not exclude the existence of documentation. It must be! There is simply no other option.

Only after all the parts of the subject area have been put together in your head can you move on to solution options.

鈫 Table of contents

matching solution options

Matching solution options

Hopefully, you have previously researched and understood everything that is required. OK, now you can start thinking for real.

Yes, choosing the right option is sometimes extremely difficult, because for the chosen variant it's necessary to be responsible.

馃 Responsibility is the biggest fear of almost everyone.

Each option must meet several requirements:

  • Solve the problem.
  • Must be implementable in adequate time.
  • Not "break" the architecture of the application.
  • It should not introduce "trash" and unnecessary "crutches".
  • Easy to use for the end users.

Have you chosen your options? Now, try to choose the one that is more useful. There are two frontier states here:

  1. It's done quickly, but it's a one-time solution;
  2. It takes longer, but it's universal;

Oh, but we need to choose something in between... To make it as efficient as possible, there are some little tips I've learned during more than 12 years of development in different teams.

鈫 Table of contents

Do not put into your code features that you do not need now

Immediately cut off the idea of features that you do not need now, but may need in the future. Usually, these features will "dead load" with ~70% probability.

鈫 Table of contents

Trying the chosen option on your picture of understanding

And if I tell you that the chosen option is wrong? You will, of course, answer that it cannot be, because you have already gone through a bunch of options and chosen the right one.

OK. So be it! But what happens if we start to implement it? What are the odds that nothing will break? Just these questions need to be answered at this stage.

For a better understanding, I will give you an example of the Ansible approach.

鈽濓笍 For those who are not familiar with Ansible, it's a tool to automate the processes of deploying off-the-shelf infrastructure on a remote server. Please, read the official docs for more information!

Ansible has a special mode of operation, called "dry run", where it "plays" the given playbook (file in YAML format), but does not make any changes. After making sure that the option does not "break" anything, Ansible runs the real change process on the target server.

Similarly, you need to "dry run" in your head the chosen implementation and see what it will affect. And if there is a chance to "break" something, we go back a step and look for new options.

鈫 Table of contents

Specifying details

Some additional data or examples may be needed before implementation.

If you have gathered everything you might need, you are ready. At this point, you have to understand that nothing is stopping you from writing code:

  • Network works.
  • Software licenses are alive.
  • Your chair and table are comfortable.
  • Coffee or tea poured into your favorite mug.
  • ...and so on 馃槈

鈫 Table of contents

Implementing

At last, we're writing code! Don't get too excited, this has its own pitfalls. It's highly probable that you will find things you haven't considered while writing the code.

馃し鈥嶁檧锔 Well, it happens! But let's not stand still and move on. It's important not to panic and not to consider it your fault.

Just answer the question: does the new data interfere with realization, or is it just a correction? If they only make clarifications, then you are lucky, and you can move on.

But if they interfere with the implementation, then we go back at least three steps. Yes, you read that correctly. In a critical scenario, it's better to go back and go all the way again with changed data.

OK. But what about task's deadline, if I've to turn back?

That's exactly what many people are afraid of and can't accept responsibility for the implementation option they've chosen. And there is one simple recipe that has more than once saved me and my development team from inevitable technical debt and bad decisions.

馃幆 Let's take our time and do it right, not the way they make us do it.

Just talk to the person who gave you this task and try to explain the difficulties. Learn to assert your right to create truly great code!

鈽濓笍 I assure you that no project manager would want to explain to a client after the project is delivered that the resulting product (although it works now) has many unaccounted for moments that may be a problem for the project's development in the future.

鈫 Table of contents

Photos and videos by

P.S.

If you want more 鈫 write a comment below & follow me. Thanks! 馃槝

Discussion (0)