DEV Community: Irek Mirgaleev

Team Lead’s Guide: How to Deliver Software Effectively

Irek Mirgaleev — Tue, 19 Nov 2019 02:59:40 +0000

Since stepping into the role of Team Lead at my current place of employment, I have perfected a technique for leading scrum-based development teams through planning and delivering features*.* In this blog post, I will walk you through the 9 steps you should take, starting from the very first time you hear an idea from the product owner through to when the new feature is released.

Real world scenario

Let’s say I work for a company that provides a time tracking app (think of Toggle or Clockify). Imagine that one of the most requested features for the app is an advanced Reports page where users can see a breakdown of time spent on various projects. Using this scenario as an example, I will demonstrate how to deliver software effectively in 9 steps!

Overview of Steps

Somebody proposes a new feature (this could be a UX team member, product owner, customer, etc.)
The UX team creates mockups and wireframes for the new feature
The UX team, product owner, and the Team Lead discuss the mockups to make sure that it’s clear how the feature is supposed to work
The Team Lead and the product owner show the mockups to the development team
The Team Lead drafts the initial plan for how to build the feature and deliver it to customers
The Team Lead shares the plan with the team, who help to refine it
The team estimates each task in the plan
The team plans their sprints
The team sprints until the feature is released to customers

Roles involved

Product owner
UX team or an individual designer
Team Lead (a.k.a tech lead)
Development team

1. UX proposal

After doing some research and design, the UX team proposes the following wireframe for the new Reports page:

The designer creates a wireframe

2. Product owner meets the Team Lead

The product owner describes the proposal and shows the wireframes to the Team Lead. Before accepting the work, the Team Lead verifies the following:

The wireframes don’t miss anything crucial
What the expected outcome is, in terms of business goals
Which metrics should be tracked
Whether there are any other specific requirements

Before proceeding, the product owner and the Team Lead work with the UX team to clarify any of the points above. The Team Lead must have a sufficient* understanding of the requirements of the new feature and the desired outcome.

*In my experience, it is often the case that no one has a complete picture of the proposed solution (or even the problem!) before the development team starts planning how to build the new feature or even before they ship the first iteration.

3. Team Lead Meets the Development Team

The Team Lead then presents the proposal for the new feature to the development team, making sure the big picture makes sense to everyone. At this time, the team is encouraged to ask any clarifying questions. There is no implementation planning at this point.

It’s a good idea to include the product owner in this meeting so they can listen to your version of the proposal and make sure it lines up with their vision. This way, everyone gets on the same page!

Once the team has an idea of what’s coming down the pipeline, the Team Lead starts working out an initial plan.

4. Team Lead Creates a Plan

This section describes the holy grail approach for quickly building and delivering large features when you are running a team of several developers. I will show you how to break down the requested feature into smaller tasks which can be worked on simultaneously by several team members.

To start the initial plan, the first thing I do is copy-paste the wireframe provided by the UX team into a Google drawing and outline the major UI components that the team will need to build for the new feature:

Team Lead outlines future Angular components over the wireframe

There are a couple of benefits to outlining the future components in this way (especially if your front-end is built using a component-based framework such as Angular or React):

The outlined components suggest the names you will use in the code so when you get to work on the task, you can jump into writing the code for the component instead of thinking how to name it
The outlined components show what pieces we need to build overall
When the feature is broken down into individual tasks and you’re working on one of those tasks, this outline is very convenient for looking up how the component you’re building fits into the bigger picture. Especially useful for bigger projects!

So here is an example of the initial plan that I would write for implementing the new Reports page for our time tracking app:

Scaffold the new Reports page
Scaffold the data service for the new Reports page
Build component: daterangepicker
Build component: bar-chart
Build component: summary
Build component: pie-chart
Build interactions on the new Reports page
Build analytics gathering for the new Reports page
Test the new Reports page and adjust if needed
Polish the UI of the new Reports page
Release the new Reports page to customers

It really starts as simple as that: Just a few bullet points in a plain text, usually written in a Google doc so it can be easily shared and edited.

I don’t involve the team in writing the initial plan just yet. (They are usually busy with whatever else is going on in the sprint.) It’s much more efficient if I come up with some initial way to build the feature and then show it to the team as a starting point. We then figure out together whether the plan makes sense and what we can do to improve it.

The way those tasks are laid out in the plan is crucial for successful execution. I will go over each task in detail in the “Sprint execution” section. The next step is to show this plan to the team.

5. Team Lead Shares the Plan with the Team

The Team Lead shares the plan with the team to figure out whether the approach makes sense and how to improve it. After the discussion, the initial plan might change somewhat as the team’s shared experience shapes up a better way of delivering the feature to customers.

Once everyone agrees on the plan, it’s time to go over each task, fill in the details, estimate the effort, and plan out sprints.

6. Team Estimates Tasks

Next, the team works through the list of tasks from the plan and figures out how much effort it will take to complete each task. Before I ask the team to estimate the task (which is done via planning poker), I write down all the things I think it will take to implement this task. Then I ask the team to see if I missed anything. (This all happens during a teleconference meeting while I’m sharing my screen with the Google doc.)

After a discussion, we usually have all the points listed for the task and then each developer gets to vote on how much effort they think the task will take. We use story points for this, but your team can use whatever estimation technique fits the team.

The details that we figure out together for each task always include bullet points about what needs to be done as well as examples of the previously completed similar pieces of code, links to relevant files in GitHub, or links to articles on Medium or whatever else would help the person who gets to work on the task.

Below is the example of what the first task looks like after we figure out how to build it and estimate the level of effort (assuming the app is built using Angular):

Task: Scaffold the new Reports page

Add a new Angular module: “report”
Add a new Angular router path: “/app/report”
Add a new Angular component: “report”
The new page should be accessible in production by visiting the URL path
The existing UI should not link to the new Reports page so that no customers can discover it yet
(link to the existing router config in GitHub for an example)
Story points: 3

The amount of detail spelled out for each task depends on the task’s complexity and risk, as well as the team’s overall experience working on similar tasks. One benefit of this activity is that the team learns more about the feature that they need to build and how individual tasks make up the whole.

Going over the entire list of tasks in a single sitting is a daunting job. Usually, after going through a few tasks, the team will get tired, distracted, and eager to get back to their day. I have found that limiting the planning/estimation meeting to 30 minutes, twice a week (usually right after our short scrum meetings) is far more effective. This way, the planning meeting doesn’t take much time from the developers’ day and by the time the next sprint starts, we have all the tasks estimated and discussed and ready to go. An added bonus: The final planning meeting before the next sprint is usually very quick!

Once, the team figures out the details and the level of effort for at least a few tasks, it’s time to start taking these tasks from the Google doc into the tracking system (e.g., Jira) and put these tasks into the sprint backlog.

7. Sprint Planning

At this stage, the Tech Lead converts the tasks from the Google doc into tickets in the tracking system (e.g. Jira) used by the team. Creating the tasks in the tracking system after the plan is solidified in the Google doc saves a lot of time. You don’t have to deal with renaming/updating stuff in the tracking system because you already did it in the doc!

An example of Jira sprint planning board after the task has been created, based on the Google doc:

Planned out sprints to deliver the new Reports page

As your team continues doing the estimation sessions a couple of times every week, your sprint planning board gets filled with tasks with specified details and estimated effort. This is a sure recipe to make your product owner happy. Looking at this board makes it easier for them to prioritize the work if there is something else the team needs to work on. It also helps the product owner estimate the delivery date for the feature.

The next step is to start building the damn thing!

8. Sprint Execution

Now let’s go over all the tasks required to deliver the new Reports page in more detail.

Task: Scaffold the new Reports page

Scaffolding the new Reports page creates a common area that will contain all the UI that the new feature will provide. For example, if you’re using Angular, this means declaring a new route path and an empty component that represents the new page. Having the new page scaffolded allows developers to see how the components fit together as they are building and adding them to the page.

Task: Scaffold the data service for the new Reports page

The data service is meant to provide all the data that the entire page will need. In our example this includes:

Daily hours tracked for all projects for the bar-chart component
The summary of total hours tracked per project for the summary component
The percentage of hours tracked per each project for the pie-chart component

At the time when the developers add this data service to the codebase, it will not have any functionality yet. Continue reading to see how this initially empty data service comes into play when developers start building individual UI components.

Tasks: Build component: *

These tasks include building all the UI components that the new Reports page will contain (daterangepicker, bar-chart, summary, and pie-chart, etc). This is where the scaffolded page and the data service come into play. As developers build individual components, they have the page to display those components and the data service to implement all the data fetching/preparation functionality.

The best part about having a scaffolded dedicated data service for the page is that even if the backend is not yet ready to output real data, you can stub the service methods with the mock data and continue building the component without waiting for the backend. Then, when the backend becomes available, you just replace the mocked data with real API calls. This allows the team members to work on these tasks in parallel without stepping on each other’s toes. For example, in our case, four developers can pick up the four tasks (daterangepicker, bar-chart, summary, and pie-chart components, respectively) and build them simultaneously!

Task: Build interactions on the new Reports page

This task involves all the click-and-hover state handling. Typically, when you hover over individual data points in the bar and pie chart, it shows a tooltip with info such as the ‘data point value’ and ‘date.’ Or when you click on the date range, it should pop a date range picker with a calendar. And when you pick a new date in the calendar, it would reload all the data on the page. (This would be a whole other component but I omitted it to keep things simple.)

If there is a lot of interaction that needs to be implemented, then this task should be broken down into more, smaller tasks based on the expected behavior.

Task: Build analytics gathering for the new Reports page

This task involves tracking the business metrics associated with the new feature. Remember, we’re adding the new Reports page to satisfy some kind of business goal. This task requires clarifying what that goal is / what exactly the product owner wants to track on the new page.

This might include:

Recording whether users are visiting the new Reports page at all
Recording the most popular date range that users select via the daterangepicker component
How many projects the new Reports page usually displays for an average user

Whatever these metrics are, you’ll need to make sure to set up the data collection before the feature is released to all customers.

Task: Test the new Reports page and adjust if needed

Testing the new Reports page is necessary because when multiple developers work on various parts of the new feature, it’s easy to miss something as you put the pieces together. In my experience, when you start poking at the new feature as a whole, you always find something that no one anticipated. For example, perhaps the user has 1000 projects to show on the new Reports page and now when you’re giving it a try, it won’t load at all. Or perhaps the pie-chart component was added after the daterangepicker component, and now the pie-chart won’t refresh properly as the user changes the date range! This task is about catching these types of bugs and fixing them.

It’s best to perform this task after all the pieces have been built and released to production behind a feature flag (or a secret URL parameter, or whatever technique you use to hide the work-in-progress stuff from customers). This way, you can load the new Reports page for any customer account in production and see what it looks like when presenting the real data.

Task: Polish the UI of the new Reports page

Developers should not be bothered by nitty-gritty design details while building out the pieces of the new Reports page. There should be 0 minutes spent on fiddling with margins, paddings, colors, or type fonts until all of the core functionality is in place. This allows the team to focus on what’s absolutely essential to deliver the new feature.

After the core functionality is in place, the team can then go to work adjusting and polishing all the small things that make the page look awesome!

(This approach has worked exceptionally well for me for delivering features within budget and on time!)

Task: Release the new Reports page to customers

At this point, the new page is fully tested with real-world data in production and the looks are polished. So the job now is to present the new page to customers! This might mean adding a menu item that will point to the new page, or swapping the existing Reports page with the new one; it really depends on your preferred mechanism of releasing new features to customers.

When the sprint starts, everyone can grab a task at the same time. The very first couple of tasks are just for scaffolding the new page and the data service so they are usually finished very quickly before the rest of the developers make any significant progress on the (more complex) tasks that depend on the scaffolded page and the data service. That is, building individual components such as daterangepicker or the charts.

So when the two scaffolding tasks are finished, they are merged into the master branch right away and the rest of the team updates their feature branches and gets their scaffolded page and data service available to use with their components.

As the Team Lead, you have some essential responsibilities during sprint execution. These responsibilities are outlined below.

Responsibility: Help the team see the big picture

Help the team with whatever questions come up regarding their individual tasks. Since they are busy with their tasks, sometimes it is harder for them to see the bigger picture and how their piece fits into the whole. So your job is to help them understand this better and answer whatever questions they may have.

Responsibility: Resolve blockers

If somebody learned that their task, Task B, depends on another task, Task A, your job is to make sure that somebody (or you!) makes Task A a first priority. Completing Task A will unblock the team member who is trying to complete Task B.

Responsibility: Review code

Review the code produced for each task to make sure it works as expected.

Responsibility: Help the team stay focused

Make sure that everyone stays on track and that they are not trying to solve any problems that fall outside the scope of their assigned tasks. If you are a developer, you probably know the feeling when you start discovering that your task is going to take a lot more work than you initially thought.

For example, if you’re working on the “Build component: daterangepicker” task, you might think that the user might want to specify the date range down to an hour, not just the date (e.g. 2pm to 3pm). This might lead to adding this extra functionality to the daterangepicker component which will take extra time and energy. The problem here is that this extra functionality was not included in the original scope of the task and we don’t know for certain whether the users would even want it. So the Team Lead’s job here is to make sure that developers don’t try to solve every unexpected problem, overengineer, and delay the project. In other words, the Team Lead makes sure that the team focuses on what’s absolutely necessary to build the feature and ensures they don’t get distracted by things that are out of scope.

Responsibility: Work on a couple of tasks yourself

As the Team Lead, it is essential that you also work on a couple of tasks during the sprint. I find it quite challenging to make the time for this but it is well worth it. Otherwise, it might feel like you just tell everyone what to do but contribute nothing yourself (which might not be ideal for team morale). Besides, by building a few things yourself, you get the real sense of what it really takes which is an invaluable experience for the Team Lead.

Responsibility: Retrospect

This responsibility is related to the “Resolving blockers” point but it’s more about the process overall rather than unblocking individual tasks. Sprint retrospective is the ideal mechanism for getting together with the team and finding patterns that prevent the team from delivering value.

For example, one of the biggest sources of wasted time that I’ve seen is when a developer takes a long time to address feedback on their code (e.g., a pull request on GitHub). You can see it when you look at a pull request that has a few comments from other developers but there has been no activity addressing this feedback for the past 3 days. That means the task will be shipped 3 days later than it could’ve been! The solution to this is to encourage the team to address feedback as soon as possible to get the task out the door.

Responsibility: Demo

As the team crunches through the tasks, more and more pieces come together and you start seeing how the whole feature is shaping up. This is the perfect time to show some of that to the product owner and the UX team for early feedback. This helps get everyone on board with the latest development. Sprint demo is a great way to conduct this activity.

When the tasks representing the core functionality (shown below) are finished, it’s time to wrap it up and release the feature to all customers.

Tasks representing core functionality

9. Test, Polish, Release

At this point, the core pieces are complete and now it’s time to test that everything is hooked up properly and working as expected. At the same time, somebody can start working on polishing the appearance of the new Reports page. This includes all of the little tasks that the team was deferring in order to focus on the core functionality: All the margins, paddings, colors, shades, etc. As the part of the same task, the team asks the UX and the product owner for feedback and the final confirmation that they are happy with what they see and get the approach for the release to all customers.

And the last task is to get this in front of your customers. Depending on your situation, this might mean adding the link to the new Report page in the main menu so the users see it and click on it. This might also involve some marketing activity as well.

You might think this would be the end of the story but it never is.

Maintenance

Getting the initial version of the feature out in the wild is just the beginning. After that comes learning whether it works as customers expect, fixing some missed use cases, adjusting other little things you might have missed and just generally learning how well the feature is received.

The feedback from customers and stakeholders sets the future development of the newly introduced feature. This might mean many things including turning the feature into something completely different or even scrapping it altogether. This is just a reality of software development.

Conclusion

In this blog post, you learned how to take the idea from your product owner and lead your development team to build and deliver it in the most effective way. I showed how to prepare and breakdown a big feature into small tasks that can be worked on by several developers in parallel. I also demonstrated how to ensure a successful execution once everyone is in full swing trying to build the thing.

Main takeaways:

Prepare the initial plan before involving the team. This way you’ll have a starting point for the planning discussion which will be a much better use of your team’s time.
Make sure you understand the requirement and overall expected outcome of the new feature before you involve the team.
Do not put any tasks into the tracking system (e.g. Jira, Trello) from the Google doc until the team filled in details and estimated the task. This will save time adjusting tasks in the tracking system in case if your initial plan changes.
Help the team to stay focused on the agreed scope and avoid chasing rabbit holes
Spread planning sessions for the next sprint throughout the current sprint to avoid all day planning meetings. This is especially relevant to teams where members are spread out across many time zones.

Notes on good software architecture

Irek Mirgaleev — Mon, 18 Nov 2019 02:23:23 +0000

Understanding software architecture is an essential skill. It allows for creating solutions that evolve the system. Otherwise, it’s too easy to drive it into a swamp from which it never recovers.

Read on, and you will learn:

why it is essential to understand software architecture
how to improve understanding of a software architecture
how to design and sustain good software architecture

Signs of poor software architecture

Poor architecture can show in many ways. The code is hard to test, change and debug. The system is fragile. It’s also prone to security and performance issues. And no one fully understands it.

Know your architecture

1. Ask someone for an initial walkthrough

The codebase is first the place to look, but it’s best to start by asking someone familiar with the system to draw a few boxes and arrows to visualize the main components of the system. Then you can find those components in the codebase and go from there.

2. Use debugger to generate stack traces for main endpoints

One of the best ways to figure out how a system works is to use a debugger.

Find a line in the codebase. Then place a breakpoint and execute the code. A debugger will generate a stack trace.

The stack trace can show all major components that were involved in producing a response to the request. When studying those components, focus on their purpose and not implementation details.

3. Document what you learned

It’s a good idea to write things down as you learn. Otherwise, it’s too easy to forget important details. Once you document your knowledge, you can present it to a group for feedback.

What is good software architecture?

Before trying to create a good architecture let’s define what it means.

it expresses its purpose and responsibilities
it is relatively easy to make additions and adjustments
it is technology/framework agnostic

How to create good architecture

Use the following to help you create good architecture.

1. Follow principles of clean architecture

Uncle Bob is a software development veteran. His advice comes from decades of experience.

2. Have a vision

Requirements should dictate the architecture of a system. Therefore it is highly beneficial to figure out why and what you are trying to build. This idea leads to the next point.

3. Do some design upfront

Scaffold main classes/services and their interfaces before diving into code. You can even stub methods/endpoints with mocked data and build the first proof of concept.

4. Use Domain Driven Design

Domain Driven Design is a methodology that bridges business domain and system implementation. It helps to ensure that the core of the system architecture is entirely dedicated to its business purpose.

5. Use Test Driven Development

TDD helps you in creating better interfaces. Classes end up having better-defined roles and are easier to reuse. And this is just one of many benefits of TDD.

6. Follow SOLID principles

SOLID is a set of principles promoted by Uncle Bob. Learn more at butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.

7. Design for change

Lastly, the only constant in software is a change. So design your architecture to be flexible.

Use an agile framework

Irek Mirgaleev — Mon, 18 Nov 2019 02:19:23 +0000

You can hire the best engineers. You can show them what business problems you are trying to solve. However, if they cannot deliver results efficiently, none of this will matter.

This post is an introduction to agile software development. You will learn:

How organizations built software before agile.
Why agile is better.
What is Scrum and how it works?
How your team can use Kanban to build software faster.

Before agile and why it did not work

It usually takes a few steps to create and deliver software:

Flesh out requirements
Design
Build
Test
Deploy

In the old days, organizations would spend months and even years in each stage before they finally deliver software to users. We call it waterfall.

As time showed, the waterfall approach often fails due to one significant flow. It assumes that the organization knows all requirements, constraints, issues and potential scope changes before developers start coding. Turns out, knowing the future is nearly impossible.

Meet Agile

In 2000s engineers formalized a different approach. An approach where an organization does not assume that it has all information upfront. Instead, it plans, designs, builds, tests and deploys a system within weeks rather than months (with limited functionality). They called it an iteration.

After each iteration developers and business evaluate the outcome. Based on this evaluation the team plans the next iteration. This allows teams to adjust to any unknowns discovered in the previous iteration. For example, new customer feedback, change in the market or an issue in the deployment process.

Start with Scrum

Scrum is the formalized approach to agile development.

Scrum defines the following roles:

Development team.
Product owner. He or she takes input from executives, customers, and other teams. This results in a list of requests for the development team.
Scrum master. He or she helps the development team to overcome blockers.

In Scrum, a development team delivers software in iterations (sprints). Each iteration typically lasts 2-4 weeks. Each iteration consists of the following steps:

The product owner tells the team what the business wants. This takes the form of a product backlog filled with user stories. The product owner sorts the stories by priority.
Planning: the team reviews the backlog and plans how and how much value they are going to deliver in the next sprint. The team estimates the size of each task and fills in the sprint backlog. Tasks in the sprint backlog represent the team’s commitment to finish the upcoming sprint.
Execution: during the 2-4 week period the team members work to finish all tasks in the sprint. They discuss blockers during the daily scrum. The scrum master helps to resolve blockers or any other issues.
Review (demo): the team, the product owner, and stakeholders review the delivered value. For example, showing a new feature in action to stakeholders or customers.
Retrospective: the team, the product owner, and the scrum master decide if the team fulfilled their commitment this sprint. They analyze what went wrong, what went well and what they can improve.

Then the cycle repeats.

Continue with Kanban

Some of the most significant challenges in software development are scope creep and emerging requirements. The iterative nature of scrum enables organizations to face those challenges and adjust accordingly. For many businesses, this is the main reason for adopting Scrum.

However, there is another advantage in doing 2-4 weeks iterations. It comes in the form of the retrospective. It enables teams to review their process frequently. As a result, they have opportunities to improve the way they deliver value incrementally. Incremental process improvement is the essence of Kanban.

The focus of Kanban is to reduce waste which is another big challenge for organizations.

Kanban principles:

Change management: make incremental improvements to an existing system. In our case, the current system is based on Scrum.
Service delivery: focus on delivering value to the customer.

Kanban practices:

Visualize your workflow.
Limit work-in-progress.
Manage flow (eliminate bottlenecks, maximize production)
Make policies explicit. For example, what is the definition of done for your team?
Feedback loops. Scrum already covers via sprint review and retrospective.
Improve and evolve.

The above shows that Kanban naturally completes Scrum. It relies on scrum to provide an initial process for agile development. Then it guides an organization to improve that process. In the end, it results in a gradual increase in team velocity while ensuring customer value focus.

Conclusion

In this post, you learned that before agile, organizations used the waterfall approach for building software. You saw that without a feedback loop it did not work. Scrum solved this problem with an iterative approach with tight feedback loops between business, customers, and developers. You also learned how Kanban could complement Scrum by helping to eliminate waste and increasing team velocity.

Create continuous delivery

Irek Mirgaleev — Mon, 18 Nov 2019 02:09:09 +0000

Successful developers do three things well:

They know technology.
They understand the business problem.
They deliver the solution on budget and on time.

In previous posts, we learned about technology and business. With that, you can figure out what business problem you’re trying to solve and how to solve it. The next step is to build and deliver the product as fast as possible. Continuous delivery plays a crucial role in achieving this goal.

What is continuous delivery (CD)?

continuousdelivery.com defines it as follows:

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes, and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

In practice, this means decoupling your system and automating your process. This includes steps for testing, building and releasing code to production.

Advantages of continuous delivery

Because CD streamlines the deployment process, developers are not afraid to push new features as soon as they built them. This results in smaller and more frequent code releases, which brings few advantages:

You can quickly learn whether you’re making the right thing. For example, you build a simple notification widget for your product and release it using CD. Later you find that it doesn’t move the needle for any of your business metrics (session length, new subscriptions). As a result, you know that you should stop wasting time on a useless feature and move onto the next thing.
You can quickly learn whether you’re building the thing right. For example, you add a first version of the chat feature for your product. Users love it and use it extensively. At the same time, you learn that this feature results in sudden bursts of server calls that cripple your site. CD allows you to roll back the feature to restore the site and re-think your approach.
CD improves team morale and trust in the engineering by allowing to fix production issues faster. This is possible because streamlined releases process results in smaller production issues. And you know that a team can fix problems quicker and with less effort. Therefore, organizations tend to focus on solutions instead of playing a blame game.

How to setup continuous delivery

On the most basic level it takes three steps to deliver software:

Add code.
Test.
Release to production.

Anything that goes in between is unique to every team. Therefore, it’s really up to the team to figure out what gets in the way of delivering a result. However, there are few primary tools and patterns that every team must utilize to create CD.

Use version control

Version control provides two features that are essential to CD:

Ability to integrate code changes into existing codebase (branching/merging).
Ability to create snapshots of the codebase (tags). These tags can then be deployed to production. If a new tag contained a bug, a team can deploy an older tag and quickly restore the system.

Automate tests

It is impossible to release software frequently without testing it. Obviously, you need to write unit tests in the first place. Ideally, most of the code is covered by unit tests. They usually run faster and are most straightforward to automate.

In addition to unit tests, there can be integration and acceptance tests. However, they are slower. Also, they are harder to automate. Therefore, it is well worth it to optimize and automate the unit tests first.

Create deployment pipeline

The previous steps ensure that your teams can integrate changes into the codebase and run tests. The next step is to create a deployment pipeline that automates the whole process. In the deployment pipeline, code changes go through several stages. Each stage serves some purpose. This includes building the source code (if necessary), running all tests against it, etc. In the end, it verifies that the change does not introduce any regressions.

An example of a simple continuous delivery pipeline can look something like this:

Conclusion

In this post, you learned why it is essential to ship code to production as soon as possible. You also saw how continuous delivery enables teams to achieve this goal. Also, you’ve become familiar with how to create continuous delivery and what are its main components.

To further explore the continuous delivery I highly recommend checking out https://continuousdelivery.com.

Eliminate constraints

Irek Mirgaleev — Mon, 18 Nov 2019 02:04:29 +0000

In previous posts we learned that a professional software engineer has to know 3 things:

Technology (how to build a solution).
Business (the problem you’re trying to solve).
Process (how to build and deliver the solution efficiently).

We learned that an efficient process requires continuous delivery and an agile framework. In this post, you will learn the last piece of the puzzle which is about eliminating constraints.

What are constraints?

A constraint is something that obstructs you from achieving some goal. For example, you want to complete your task within 2 days. However, it takes other developers at least 3 days to review your code. This slow code review process is a constraint.

Why bother eliminating constraints?

When you remove constraints from your process you get stuff done faster. Let’s look back to our code review example. Let’s say you convince other developers to review your code within 1 day instead of 3 days. As a result, you’ll end up finishing your tasks faster. It’s as simple as that.

How to eliminate constraints

1. Document your workflow

It takes a number of steps to turn an idea into a successful software product. Every team finds their own way to establish this process. Therefore, prior to finding constraints, you need to know your process.

Here is an example. A while ago I worked with one of the teams at Acquia. We noticed that some of our tasks were taking a long time to finish. So we broke down the life cycle of a typical task. It looked like the following:

Pick up the task and start working on it.
Post the code for review.
Receive feedback.
Address feedback.
Repeat the above until the code is approved.
Release to production.

2. Measure time in each step

Once you determined all steps in your process you need to know how long each step takes. Tools like Jira provide convenient metric tracking for this kind of thing. For example, you can see how long each task spent in different statuses. These statuses might include todo, in progress, in review, ready to release.

3. Find waste

The previous step shows where you need to improve things.

My team at Acquia found that tasks spend a lot of time in the review status. So we looked at commits and comments in our GitHub pull requests. What we learned is that when you post code for review it takes a while before anyone visits it. We also learned that after the code receives feedback it takes the developer a while to address it. We concluded that these delays in the feedback-response loop caused overall slow lead time for many tasks.

4. Reduce waste

The way you can speed up slow steps depends on the nature of the issue.

In the case of the slow review process as a team we agreed on the following:

Provide feedback to other code reviews within 24 hours.
Address feedback to your code reviews as soon as possible.
Don’t have more than two tasks in progress/review.

This reduces wasted time when tasks were just sitting in a queue. In the end, each individual task was completed faster. This resulted in an overall increase in velocity. In other words, we got more stuff done in less time.

It’s all about the journey

This process of continuous improvement is an ongoing battle. Soon after you improve your process in one place you learn that it is struggling in another place. And so on.

Check out my other post where I a model where a team can start with Scrum and continue with Kanban.

To learn more about this topic I suggest to read these two fantastic books:

Impact mapping for software developers – solve the right business problems

Irek Mirgaleev — Mon, 18 Nov 2019 01:54:18 +0000

At any given time you probably have a couple of tasks that you are working on at your current job. Can you confidently say that you have a clear understanding why these tasks are important? Alternatively, can you say that you know how these tasks contribute to any of the goals of your organization?

I rarely asked these questions at the beginning of my career. I just did what dropped in my queue. However, one day the circumstances put me in the position of a team lead. Therefore, it became my responsibility to decide what tasks we pick and drop.

That is where I realized how easy it is for a developer to just grind in the routine of busywork. As you know, busy work does not make you a successful developer. You become successful by making your team or organization reach their goals.

Read on, and you will learn a powerful technique. The technique that you can use to make an impact and become more successful in your engineering career.

What is impact mapping?

Suppose you are working on a new feature for your product. You or someone else assumed that this feature would help the organization to achieve some goal.

Impact mapping is a technique to expose these assumptions in a clear visual way.

It allows everyone in a team to see why they are doing the things they are doing. It aligns everyone with the same goals. As a result, by looking at an impact map, you can tell whether your current work relates to what your organization defines as success.

How to use impact mapping

Below is an example of an impact map for online teaching service. Think of www.udemy.com for instance.

Example of an impact map for online teaching service.

The goal (why?)

Everything you do should serve some goal. In our example, the goal is to reach $1M in revenue by the end of the year:

In an impact map, everything converges to the goal.

Actors (who?)

Then you define whom you can involve in achieving the goal. In our example, we have prospect students, existing students, course instructors, and the internal engineering team.

Actors in the impact map.

Impact (how?)

Next, you figure out how these actors can get you closer to the goal. In other words, you define what kind of impact they can produce so that you can achieve the goal.

The desired impact produced by actors.

Deliverables (what?)

The last step is to come up with ideas for what we can do to enable the actors to produce the impact. Impact mapping defines these ideas as deliverables.

Deliverables to enable actors to make an impact.

Benefits of using the impact mapping

It provides context to why specific features are critical. For example, we are investing in a recommendation system because we believe that showing related courses will encourage students to buy more and get us closer to the goal.
It prevents the scope creep when others try to push features and ideas that do not contribute to the goal.
By looking at the impact map, you can see the direct connection between the work you are doing and the goal to which it is supposed to contribute.

“But I am a developer, not a product person.”

Yes, you can write great code. Moreover, you can be an expert at the technology you use to build solutions to business problems. However, if you do not fully understand the business problem and how it relates to organization goals, it is too easy to waste your talent building a wrong thing without even knowing it.

When business people tell you to build a specific feature, you can try to draw an impact map to understand better what they want to achieve. It will expose their assumptions in a clear visual way.

As a result, you will have a better idea of the desired outcome. This knowledge will empower you to solve the right business problem. At the same time, such an approach makes it less likely that you will spend precious time on things that make no difference.

Conclusion

In this post, you learned why making an impact is crucial to becoming a successful software developer. You learned that impact mapping is a powerful technique that can help you to achieve this goal. You saw how to apply the impact mapping technique in your position as a software developer.

To learn more about the impact mapping visit https://www.impactmapping.org.

Best software engineering practices and principles

Irek Mirgaleev — Mon, 18 Nov 2019 01:44:53 +0000

Following the best software engineering practices is only a part of being a highly effective developer. If you want to deliver the best result, you need to do three things:

Know which change will make the most impact.
Implement this change by delivering high-quality code.
Do it on budget and time.

In this post, we will focus on the second point: delivering high-quality code.

Use the following practices and principles to produce robust bug-free code; code that doesn’t break in production; code that’s easier to read, change and maintain.

Coding standards

Coding standards ensure the same code format across an entire project. It enables faster reading and comprehension of code. It is much easier to read through code that uses the same conventions for main structs such as curly brackets, variable/function naming, indentation, etc. Coding standards is one of the most essential best software engineering practices

Examples of coding standards include:

use camelcase instead of the underscore in function/variable names
use two spaces for indentation, no tabs
no spaces between the name and first parenthesis in function calls

The best way to ensure coding standards is to include it as a part of an automated build process. For example, in my team at Acquia, we use eslint automated by gulp which runs on each code change. It validates all code formatting rules and fails in case of a violation.

Code reviews

In my experience, code reviews proven to be one of best software engineering practices. Code reviews work as follows:

Developer submits a patch for a review. For example, in the form of a Github pull request.
Other developers review the changes and comment about potential bugs, improvements, and gotchas.
The author addresses these comments, makes updates to the code and submits an update patch for another review.
Steps two and three repeats until everyone is happy and the patch merges into the codebase.

Issues with code reviews and how to deal with them

Although code reviews is an essential part of code quality, it can also be one of most challenging parts of the process:

It might take a while for others to provide feedback for your patch which forces you to switch context and work on something else.
If you get busy with other tasks, it might get a while until you address feedback received for your patch. As a result, it takes longer to ship the change.
Sometimes you might disagree with feedback posted for your patch. Then you have to choose: either just apply the requested change or start a potentially lengthy unproductive discussion.

The first two issues are easy to fix. As a team, you can agree to provide feedback within X hours. Preferably, every team member should allocate a couple of slots each day for reviewing patches. For example, 30 minutes in the morning and 45 minutes in the afternoon.

The issue with disagreeing on feedback is trickier. Personally, I always strive to finish my task as quickly as possible and just apply the requested change. But I only do it when I am confident that requested changes don’t introduce long-term adverse effects. Otherwise, I’m willing to get into a discussion and spend precious time to understand why a change is necessary.

Test-driven development

TDD is by far my most favorite item among best software engineering practices. It guides code development by following the three rules:

Do not write any production code unless it is to make a failing unit test pass.
Do not write any more of a unit test than is sufficient to fail, and compilation failures are failures.
Do not write any more production code than is sufficient to pass the failing unit test.

You usually start by writing a very first failing assertion. Typically this assertion fails due to a missing class, method or whatever you’re testing against. Then you add a little bit of code just to make that assertion pass. Next, you add another assertion that tests a happy path for your code. Then you make that assertion pass by writing just enough code. Next, add assertion against other paths and make it pass. And so on until the code does what it should do. Then you polish up the code while making sure the tests pass.

Benefits of TDD

You always end up with high test coverage.
You naturally write better tests. It is because you are forced to think about your code regarding expected behavior (interface) as opposed to implementation details. If you write tests after the code, you tend to assert against implementation rather than interface which is a recipe for fragile tests that add problems and no benefits.
You end up with just enough code to satisfy expected behavior. Less code — fewer bugs and maintenance.
It provides focus because you always have the next step: write a failing test, make a test passes or refactor.

End-to-end testing

End-to-end tests simulate user interaction against the production system engaging all layers of a stack starting from Javascript that runs in a browser down to database servers including everything in between.

However, end-to-end tests are known to be fragile, slow, hard to debug and maintain.

To minimize these issues only write end-to-end tests for most critical parts of your system. Other areas should be covered by unit testing and monitoring. However, I still believe that end-to-end testing is one of the best software engineering practices.

Design patterns

As engineers, we have been writing code for decades now. There is a set of problems that we have to solve over and over again. These are well-known problems that have a set of well-known solutions. Meet the design patterns: https://sourcemaking.com/design_patterns.

The design patterns can help when:

Object creation is too complicated for consumers (can be solved by the abstract factory pattern).
There is a need to use a third-party library, but its interface doesn’t fit into an existing architecture (can be solved by the adapter pattern).
Your data is stored in many different ways, but your algorithms need to be able to traverse it uniformly (can be solved by the iterator pattern). Use these patterns instead of re-inventing the wheel.

SOLID

SOLID is an acronym for five principles promoted by Bob Martin. They allow writing code that’s less fragile and easier to change.

The principles:

Single responsibility principle: a class should have only one reason to change.
Open/Closed principle: a class should be open to extension and closed to modification.
Liskov substitution principle: a parent class can be replaced with its child class without breaking any consumers.
Interface segregation principle: create more specific interfaces rather than general interfaces.
Dependency inversion principle: consumers should depend on abstraction rather than concrete implementation.