How to define tasks to help developers with their work

Michal Iwanowicz

Order execution is usually related to the creation or repair of something. In most cases, one person invents something; the second one realizes it. The thing that links these two people - the designer with the contractor - is the TASK. This subject is important because all of us (bosses, managers, low-level workers, programmers, physical workers, etc.) have to know what needs to be done to achieve the goal - we have to KNOW, not GUESS.

Task definition can be any document that helps others understand WHAT and HOW should be done to realize a new feature or fix an existing one. This article describes how tasks can be defined to make them ready for estimation in terms of time (and costs of course) and realization, bearing a very low risk that the deadline isn't met.

What are the advantages of a well-defined task?

The better requirements are defined, the smaller mistakes that happen during time estimations. If we want to promise someone that a task will be completed before the deadline, we have to know how much time we need for its realization (otherwise, we can't be considered as experts - sorry). Of course, we might be lucky and estimate the time properly, but it's too risky to be serious.

The ordering party is sure that the result will be as they wish - the contractor doesn't have to guess what they want (conjectures are usually a source of misunderstandings).

We should know what the purpose is and what should be done to achieve it. If you decided to start working on the task, you shouldn't have additional questions about this task that could become significant blockers. The next thing is problem reporting ASAP - you HAVE TO alarm the supervisor that you encountered a problem during the work on the task - they need to know that and should help you. Next, if you're not able to estimate a task, feel free to create additional "investigation tasks." Such tasks come in handy for preparing the necessary knowledge for realizing a given task - it's a manifesto of professionalism, it isn't a triumph of form over content because you say that you see a problem out loud.

The contractor should be known so that you can contact them during task execution or afterward to provide feedback (both positive and negative), or just to ask about something.

Well-defined tasks don't require any additional work, questions, and time spent waiting for the answers - all of these things are distractors, making tasks more time-consuming and less attractive. We often start working on the next task while we're waiting for an answer regarding the first one. This isn't a good solution because when we get the answer, we need to get back to the previous task, recall what we did there and where we are now - and only then go forward. The same happens when we get back after some time to a task that we've already started.

We have to specify the goal. Otherwise, the contractor doesn't know if the task is done or not - the expected effect has to be known.

A well-defined task needs to contain as much information as is required to deliver the result. It's ideal when we know what knowledge the contractor has and don't need to describe everything with unnecessary details (I know myself best) - it obscures the content. On the other hand, we can suppose that the programmer doesn't know enough about logistics in a transport company - the task creator should provide all the required details to enable the contractor to implement business logic. In the end, we have to remember that outside special cases, "How to do it?" should contain a business description rather than a technical one.

It's very good practice to add a short description of how to test the task and the acceptance criteria - it's mainly for testers or business guys.

If we decided that we'd realize our task in time slices, we should always assign a person who will be responsible for that task. It's mainly useful for that person - thanks to this, they can schedule the tasks in better order and finish them on time.

It may happen that despite a good definition of the task, the contractor will need to contact a person who knows more about this task - the creator, someone who knows the domain, or teammates with more experience - to resolve problems or suggest something. It's good to know who could (probably) help us. This is a particularly important point for new team members.

"Isn't the task too big?"
"Maybe we should split this…"
"I think that this task is too small…"
"We can realize these 2 features as part of this task - don't waste time creating another one…"

The task size is one of the most common problems during the process of defining it. We wonder about how large it should be, how many features we can describe, etc. There is no good answer to this question (maybe one: "It depends" - but we hate this answer). However, we can try to answer this question: "Can we extract an independent part of this task?". If yes, then JUST DO IT! Of course, if tasks depend on each other, we have to organize them in an appropriate order to be able to process them as separate tasks.

One of the best approaches to creating tasks is to start from the end (goal). Let's imagine that we have to create an IT system for a transportation company… The goal is to build the whole system but we can easily indicate its components: GUI, databases, services, hardware infrastructure, etc. We can treat each of these components as separate parts of the system and divide them again and again. In the end, we should have tasks which are small enough to be doable at a finite amount of time by an executive unit (person, team, company). It's just an example - we have to remember that task complexity is different for people: "an IT system of the transport company" can be an indivisible task for the management of the transport company but it's a big project for the contractors which will (probably) be divided into hundreds (or thousands) tasks.

We have only described how to define tasks so far, while the main subject of this article is an effective feature delivery. That's right, but as you remember, I said that the task is what we find between client and contractor. So, no well-defined task = no effective delivery. Every client wants their order to be completed in the right way - this is what they pay for! To make that happen, clients need to know what they want and contractors need to know what needs to be done. If there is no understanding here, there's a good chance that tasks won't be done properly - something may seem obvious to one person, but it might not be that obvious to someone else. I think it's clear that a poorly-defined task is a fault that lies on both sides:

the ordering party should define the specification clearly and in detail

the contractor should inquire about unknowns/details.

I hope that you know now why such a big part of this article is about task definition.

Of course, we can deliver tasks without a good definition, but it's risky. The system can work properly but doesn't care about corner or random cases. Let's go back to the system for a transportation company… the system works, there are no issues, but it doesn't care about traffic jams or road accidents - in this situation, we cannot trust a system which, for instance, prepares the customer service timetable.

Additionally, we should remember that many projects are huge and time-consuming. Such projects can't be prepared at once in detail, and that's why the tasks shouldn't be prepared well in advance. You may have to redefine a task later on, and there will be time for all this.

It would be enough to write: "Define tasks so that the contractor doesn't have to ask you any additional questions!" - THE END. If you order something, you have to believe that the contractor can use tools to reach the goal but doesn't need to know your domain very well. The contractor is a professional in their domain - and you are in yours! So, if you want to get a well-done product, provide well-defined tasks and be ready to assist the contractor - then both you and the contractor will be pleased with the results. On the other hand, if you're a contractor, it's also worth knowing what tasks should look like. Why? Because YOU will be working on them, and YOU will be accounted for them.

PS. Everybody knows that task definition is the hard part of the job, but remember...

How tasks can be defined to make them ready for estimation in terms of time and realization,

Event storming is worth a shot and here is few reasons why.

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

Most developers already had the chance to hear or read about Domain-Driven Design. Long story short, this approach is meant to help in modeling complex domains by offering precise tools and encouraging the use of specific, domain-oriented ways of thinking. It is a powerful methodology that works perfectly well with greenfield projects. But what about a legacy system that was, in addition, poorly designed and maintained? The cost of introducing this approach to the entire company is huge, takes a lot of time, and requires some training courses (not only for developers). Thankfully, there is a simple technique invented by Alberto Brandolini called 

. This is a good starting point for discovering Domain and introducing DDD.

Recently, we have started to implement the Domain-Driven approach together with one of our clients, and our goal is to integrate processes for discovering domains based on different Event Storming workshop variants. In the wake of a few sessions completed so far, we have reached some insights, and we would like to share some of them in this article.

First, let's focus on the workshop itself and its most popular variant, Big Picture Event Storming, with its basics and how to facilitate it. The main goal of this workshop is to gather all people that have a business, domain, or technical knowledge in one place and model the current understanding of the system.

You might say that there is nothing special about it, right? There are many other workshops and techniques that accomplish the same, so what makes Event Storming special?

The biggest advantage that speaks in favor of Event Storming is the clear, easy, and structured way of communication between employees from different company units. And because of that, we can naturally stimulate our participants to start a dialog, discussion, share thoughts and, most importantly, to agree on the language and discover it with us.

To perform this workshop and make it successful, you need three key ingredients:

The right people - a greater variety of the group, may color the final view by reducing bias, but be sure to invite only those people who have the most influence or knowledge about a given subject and care about the problem. They will be your domain experts. Developers with long service can be useful experts too, but they need to understand that the event should be considered as business-related.

A good location - the room needs to have at least one long wall and be large enough to accommodate gathered people and give them some space.

An experienced facilitator - you need a person or two who will ask the right questions, timebox every phase, and be able to explain all the rules and stages clearly so everyone would understand them.

As I wrote before, the room needs to have a long, straight wall on which you will be able to stick paper rolls. The bigger the wall, the better. At least at the beginning, all the participants should have space to stand and walk, so you also need to move all the seats to the place or corner, which is not easily accessible. The next important thing is a table with a lot of sticky cards in different colors, a few markers and a board with a legend of what each card means.

Sticky cards are the best tool used in the meeting. In the Big Picture variant, we can differentiate between five types of cards.

Orange cards represent an event and are the main building blocks in our process. To be more precise, this is an event relevant from the domain expert perspective. Events should always be phrased at past tense. Example: Report was generated, Charging has stopped.

The yellow card represents people involved in some event or process. You can treat it as an actor as well. Remember that the goal is not to specify people for each event but to accentuate the involvement of someone outside of the system. Example: Portal user, Support team member

The violet card represents the system involved in some event or process. It can be either an external or internal system. The same as in the card for people, the clue here is to emphasize some external involvement. Example: Third party API, Database

The red card represents a hotspot. This is used for marking a place with the lack of proper knowledge, something that is not working well or to mark a place of disagreement between participants. This is a sign that we need to take a deeper look into it later. Example: Generating report takes to long

The green card represents an opportunity. It can be used for specifying something that is already working quite well, something that we can improve, or some other handy ideas. It can be a good alternative to the hotspot card for an attendee who prefers resolving problems rather than complaining. Example: Delivery reception can be automatized

Up to this point, we have a place to organize the workshop, we have the tools - but what is the process itself? To quickly answer this question, there are five different phases in this meeting:

To benefit from our long, carefully prepared paper board, we need to draw a small timeline at the top of it, explain what each card means, ask everyone to think about some events happening in the system, write down an event on the orange card, try to stick it somewhere on the timeline and do it again and again until everyone runs out of ideas. It’s easy as that! Nevertheless, we often run into a problem with starting to stick cards. In that case, you need to encourage everyone or place an example card yourself to show that it’s just placing a card on the board, nothing more. Since it’s chaotic exploration, the location on the timeline does not have to be 100% accurate but will be helpful during cleanup. This phase should not take long; if you see that no one is writing anything on the cards for more than a few minutes, you can just finish this phase. In the end, it should look more or less like on the image below.

After chaotic exploration, of course, we need to do some cleanup and sort out all the events we have gathered on the board. Unfortunately, it’s not as easy as it sounds. Some parallel processes will surely come up, people will try to kick all events around, and a lot of confusion will happen. To make this phase nice and effective, we can introduce some structure at the beginning. There are quite a few good strategies, but we highly recommend specifying a few pivotal events and introducing swimlanes. We ask our domain experts to choose up to four-five most significant events in the flow. They don’t have to be perfect; it’s enough if the other sequence of events is depending on some pivotal event and cannot happen without its occurrence. That will create a framework on the board, which makes sorting other events easier by determining whether they happen before or after a given pivotal event. We can introduce swimlanes for all sequences of events that can occur at the same time. When everything is put in order, it’s good to make a walkthrough from the first card to the last and assure everyone that they did a great job.

In this phase, we ask our domain experts to specify a few people and systems which play some role in the events. We need this information to have a full picture of the serious dependencies in the given system. It may also point to a place where there is no full control in the system, or where constraints and conditions are present.

So far, we have quite gained a lot of data about our domain, but still, it doesn’t feel as solid and detailed as it should be. To encourage our participants to be more creative and take a different perspective, we should spend more time on the backward walkthrough phase. In general, we need to ask someone from the audience to read out loud all the events starting from the last card. What is different now is that we ask additional questions like:

Is there something more happening between X and Y?

These questions will make domain experts think in different ways, stay focused, and not take something for granted. As a result, we will have new information and more details - and therefore, new events, new flows, and new structures. The most important rule here is to discuss and fill the magic gaps between events if they are apparent. There might be a situation when an agreement cannot be made due to a lack of knowledge. In that case, marking it as a hotspot is a good choice.

The last phase could be optional, but the overall picture of the system will gain a lot from that information. We would like our domain experts to specify hotspots - aspects to improve, and opportunities - ideas to introduce. After that, we organize short voting by drawing an arrow near the most important hotspot/opportunity in the system. This information is a very important sign that in any further discussion, we need to dig deeper into this area and try to solve this problem. We can also prepare a simple metric for a given hotspot/opportunity so it can be expressed with numbers, and as we know from our experience, numbers are intrinsic for business.

As you have already seen, this workshop is not so complicated from a technical perspective and probably could be performed by anyone who knows its rules. However, just as in real life, details play the biggest role. Some obvious behaviours and attitudes are often forgotten in effect, so here are a few tips that came along with practice.

Event Storming is all about the people and their knowledge. The goal is to have as diverse and useful a group as possible. To achieve that, a simple stakeholder mapping technique comes in handy. We need to find a person who knows the system and the company quite well. It can be a Product Owner or someone from the management board. Then, together, try to determine potential participants on a simple figure with two axes: influence and interest. For simplicity's sake, we can divide the figure like in the image below and map people into those areas. The conclusions are self-imposed.

Remember to make the goal of the workshop clear to everyone, especially in the Big Picture variant. People often tend to lose their track if they don't narrow the scope a little by having an explicit reason for carrying out the workshop. That may result in many wrong, or irrelevant events, so unnecessary confusion could happen by accident in further phases.

A good facilitator is priceless and makes a huge difference during the workshop. Leading a workshop is a skill that demands time and experience to be improved, but fortunately, we have some advice on that matter (especially useful if you're just getting started).

At first, keep the meeting and rules in scheduled bounds and don't allow too much freestyle. Boundaries trigger creativity and require mental effort. The next thing is about too specific questions during the Big Picture Event Storming. Not everything is important and necessary at this level of abstraction. More details should be discovered later when the scope is limited, and we have a clear goal to deliberate specific aspects. When something is not clear, just mark it a hotspot.

The last and most important thing is to focus on the language that springs out during the discussion. Domain-Driven Design puts linguistic differences first, so try to pick up details and attributes up as much as you can. Ubiquitous language is necessary to appoint subdomains, and there is no time to write down everything that has been said.

If you gather people from different company units, they could have their own definition of an event. It is really important to have a common understanding that events should be relevant from a domain expert and from a business perspective. An event should not be connected to some implementation and technical concepts because it's highly probable that it doesn't reflect the problem and domain. Often, it is far and away from the business-related issue, especially when you are considering a legacy system that wasn't designed in a Domain Driven way.

Do your best to specify good pivotal items. Ask as many detailed questions about chosen events as you can, e.g., "Are there some events that cannot happen if this event has not occurred?", "Is it necessary for some processes to start and go on?", etc.

This will speed up the cleanup phase, and in the future, it can point to a moment when the language is changing. Pivotal events often come with new processes that could be related to different subdomains.

It's hard to book at least three hours in everyone's calendar. It's even harder to stay focused and feel good during such a long meeting. Proper timeboxing and breaks are a must. Spend your time, more or less, in these proportions:

Chaotic exploration: about 10-20% of time

Enforcing the timeline: about 30-40% of the time (cleanup takes some time)

Backward walkthrough: 30-40% of the time (most of the details come up here)

Hotspots and Opportunities: max 5-10% of time

People would love to see the result of spending their precious time on discovering their domain. Also, from the perspective of a software architect, you need to have a better overall view and possibility to manage it without effort. Digitizing it seems to be the best solution, and for that, we recommend an online tool called Miro. It has a feature to capture sticky cards and convert them to online notes, which can save a lot of time.

Now that we have finished the workshop, everyone is completely exhausted but also satisfied with what they have achieved. And then they ask the important question: What is going to happen next?

The answer is simple. Now it's time for the domain architect to discover and validate the subdomains. We have a big picture view of the whole system, but we don't understand it yet, we cannot tell what exactly is happening underneath, what problems there are, and what exactly we want to solve.

We need to determine emerging subdomains. It's not easy; some even say it has more in common with art and intuition rather than logical patterns and equations. What's more, there are dozens of heuristics and techniques for doing it, and none of them are universal.

Nevertheless, here are a few worth mentioning.

This can be a good entry point for further considerations. Each organization has different units that can reflect different subdomains. Unfortunately, business processes, which are a part of the core domain, often cross different departments, so we cannot rely on this heuristic much.

It's a common situation that within one company unit, there are few domain experts responsible for different issues. This is a clear sign that we may expect different problems in one place and may need different subdomains.

Probably the most important and practical heuristic, which assumes that words and terms have a different meaning in different contexts and subdomains. Company products have different meanings in the sales department and different meanings in the warehouse department. If we don't focus on the language, we risk failing to see these various perspectives, life cycles, and issues separation.

If some aspect comes with huge business value, it should probably be a separate subdomain. You can be almost pretty sure that this aspect is connected with the core domain, the company determinant.

Many business processes often involve different subdomains. Establishing factors that highly influence the process may point to a change of involved subdomain. Finding that might require introducing a clear chronology and asking for more details about what is happening between two events.

Discovering complex domain with Event Storming

Guide to hiring an offshore team for product development.

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

Hiring an offshore team for product development.

 is of the most effective strategies companies use to achieve strategic business goals. For product development to work, organisations need to build a strategy that involves quality design, reasonable action plan, and well-charted stages of development. Only once all these elements are in place, the company can start looking for the best offshore partner to help realize this goal.

In the context of product development, an offshore company works as an extension of your internal team. Working in accordance with a development plan that you can easily share and communicate helps to keep everyone on the same page.

But why are so many businesses choosing offshore product development companies to help them out?

Benefits of offshore product development.

As local economies become globalized, many organisations consider offshoring product development to take advantage of the most talented workers on the market.

Offshoring product development comes with many different benefits:

It’s cost-effective - by outsourcing the task of developing a product, you’ll be saving up on all the costs associated with sourcing, attracting, and hiring new candidates for the job. You won’t have to spend time on recruitment, onboarding, and training new employees. Moreover, by teaming up with an offshore product development team you’ll be saving up on office space and equipment.

It helps to save time - outsourcing the entire process of product development saves the time and energy of your internal resources. By having someone else build the product, your team gets to focus on the bigger pictures.

It gives you access to top talent - by expanding your talent pool to the entire world, you get the opportunity to work with highly-skilled experts in the industry. Offshore teams often have extensive experience in their field and may have previously worked on similar projects, offering you insights into problems that might arise. Moreover, you get access to a ready-made team that has experience working together already - they have tools and processes in place to make the product development process smooth and successful.

Choosing the right product development outsourcing partner.

It’s essential to partner with an offshore company that is experienced and trustworthy. That means you need to do some research, develop a clear vision for the product you want to build and review the portfolios of potential partners.

It’s smart to create a list where you compile all the critical questions you’ll have for your potential partner. Here are some examples:

Is the vendor experienced in creating products for other companies?

Do they have a quality management system in place?

How do they approach communication, and in particular project transparency?

How much control will you have over the process and team?

What were your vendor’s biggest success and failure over the last year?

Check the company’s portfolio of case studies and references. Be sure to ask for contacts to previous clients and ask them about their impressions. A professional product development company will share these details with you right away - after all, there’s no reason to hide if they did a great job.

Sometimes a face-to-face meeting might be necessary to understand the culture of the company with which you want to team up. Why not travel to the vendor’s office? Have a look around, meet with account executives and project managers, talk to the staff and get the general feeling of the atmosphere at the company.

Key factors to consider while hiring an offshore product development company.

It’s possible to build an effective working relationship with an offshore team - but only as long as you prepare for that type of collaboration. With some careful planning and a thorough vetting process, you’ll hire a partner who will help you bring your product development project to success.

Here are some best practices to get you there:

 - make sure that your internal team has a clear understanding of why you’re entering a partnership and what your objectives are. You can focus on core business processes or simply reduce the workload of your in-house team. Once you know the goal and scope of your project, you’ll be more prepared to hire an offshore team that can help you succeed.

 - lack of communication is the most serious pitfall of offshore collaboration. That’s why you need to check that the offshore team has solid communication tools and processes in place. Consider how working in different time zones may affect your ability to reach the team during business hours. Remember to be clear about your expectations in terms of communication.

 - understand the cultural differences and customs of the target country to which you’re outsourcing. They may impact your collaboration. That’s why so many organisations are partnering with companies located in Central European, and especially in Poland - the professional culture is similar to Western standards.

Are you looking for a highly experienced product development team? Get in touch with us, we’ve developed a broad range of software products and have the skills to create yours in the best possible way.

Recruiting senior software developers by example.

 is always a challenge; this challenge can also grow depending on the candidate’s expertise. The technology involved in the role is not particularly important, what matters is the talent on offer from the candidate. If you know that only senior or exceptional skills are required then there’s one important question to ask yourself: do I really need to check their coding skills?

This, however, is a rather limited approach. Additionally, if this person has worked with the specific technology for several years, they must have succeeded in the recruitment process previously. Therefore, in this situation, how do you dig deeper and determine if the candidate in front of you is correct? Is there a particular approach you can take to uncover the candidate’s best qualities? And how can you encourage them to demonstrate the experience they have gained throughout their career?

As I can’t give definitive answers which will suit every software company, the only thing I can do is share my current approach for recruiting strong candidates for solidstudio.io.

A few weeks ago, I posted an article which looked at the pros and cons of testing algorithm skills in the recruitment process. In this new article, however, I want to look at whether designing a distributed system is a good task to set during an interview for a senior developer position. Everything here is based on my experience and the dozens of interviews I have conducted within our company.

Before we look at the required task, I just want to clarify why I feel that designing a distributed system is such a crucial skill. Sure, many people will state that the knowledge required can be learned relatively easily. However, I believe that listening to the candidate’s experience in building these systems provides a fantastic insight into their talents.

Let’s take a look at an example of my approach. In conceptual design, even the simplest problems may require highly sophisticated solutions. This is why I ask candidates to design straight-forward functionality:

Imagine you own a website that serves content to its users. Everything is there — content, design, security and scalability — so it’s now time to make some money! Your business model is to display sponsored links in a given section of the page. You get these links by fetching them from an external system — let’s call it system B. Once a user is logged in to your site, you need to ask System B for a link to be shown to this user. As time goes by, links change as the user’s preferences are likely to change as well.

System B will only pay for links to be displayed that are relevant to that individual user. Therefore, after showing the link, you need to update System B with information about user, link and timestamp. Now comes the tricky part: System B is not very reliable — sometimes it is available, sometimes it is partially available and sometimes it is not available at all. Your job is to maximise profit without exposing the failures of System B to your user.

The good thing about this task is that the amount of variation in solving it is almost endless. Moreover, you can see how candidates gather the required information regarding the system. If there is more than one recruiter in the room, one can be a product owner that verifies all assumptions and the other can be another developer to provide some healthy discussion about the system.

Now that we understand the task, let’s talk about the benefits of solving it during a recruitment session. We’ll start with technical feedback first:

- we can easily measure the experience of the candidate. The task also provides a simpler approach towards the quantity and quality of similar problems experienced in previous roles.

- the candidate’s approach to modern system designing is demonstrated and provides a vast insight into their methods. A candidate stuck with an MVC model has little to do, so this provides little insight.

- the solution can involve caching, queues, different kind of storages, synchronised and unsynchronised communication. These are all concepts which require a broad field of knowledge.

Solving this task can also help to uncover some insights about the candidate’s soft skills:

- mitigating developer or product owner role-playing can give provide an idea how the cooperation may work while working on actual projects.

- the more questions asked, the better. Gathering requirements, be they functional or non-functional, are critical in developing good software. A candidate that follows this approach has a greater chance of becoming a successful developer.

- embracing failure. In almost all the scenarios and solutions to the problem, there can be an issue that causes the designed system to fail or not meet the requirements. The manner in which a candidate reacts can give valuable insights about their work approach and how they handle tough situations.

The greatest benefit of this task is that the scenario can be pushed or challenged almost endlessly. Every time that a problem is solved it can be replaced with another. Alternatively, you can start to talk and ask questions from different perspectives and focus on other parts of the system.

Developing elegant and innovative solutions to the problems present can indicate that a candidate is the right fit for your software house. And, in most of the cases we’ve experienced, the candidate had no issue with the next step of the recruitment process: a coding task. However, when you’re looking for a senior software developer, a coding task is something that you simply cannot skip, so it’s vital that this skill is tested.

Effective feature delivery vs. well-defined tasks

30 APRIL 2020 • 8 MIN READ