Tag: developer tips

Basic Principles of Kanban Software Development

Posted on by eugene evdokimov

Kanban software development is a popular, highly visual framework that falls under the Agile methodology. It requires real-time communication of availability and capacity, allowing full transparency of all work in a team. Tasks are represented visually on a Kanban board by cards. This allows all team members to see the status of every project at any time, including not started, blocked and completed tasks.  

The Kanban methodology helps development teams improve workflow in real-time and complete more work. 

This article will explore the principles of Kanban software development.

What is Kanban?

The name Kanban comes from two Japanese words, ‘Kan’ meaning sign and ‘Ban’ meaning board. It was developed in the late 1940s by Taiichi Ohno, a Japanese engineer, on the shop floor of Toyota. In order to reduce operating costs, they began experimenting with a system that processed small amounts of raw inventory quickly. By matching inventory with demand, the Kanban system helped Toyota achieve higher quality and throughput. 

Today, Kanban software development is used by teams all over the world to complete more work in less time, with a focus on customer value.

Principles of Kanban Software Development 

The methodology is guided by four key principles.

1. Visualize Workflow

Visualizing workflow in Kanban means not only visualizing the process, but visualizing each piece of work (represented by a Kanban card) as it moves through that process. Development Teams find that making the work visible, along with blockers, bottlenecks and queues leads to increased communication, collaboration and problem solving.

Visualizing all work also helps establish accountability and transparency across the team. A blocked work item can be identified with the person or team allocated to fix it. This is invaluable, especially for development teams, which require coordinated efforts to complete their work efficiently.

To begin improving workflows, it is important to visually map the current process. Only then will opportunities for improvement become obvious. For example, the delays of a development team receiving business approval for technical designs are easier to identify and alleviate. Visualization continues once Kanban is implemented and serves as a way to communicate the state of projects and work items.

2. Limit Work in Progress

kanban work in progress

Kanban software development teams can easily get overwhelmed with their long list of work items; such as coding project work, fixing production issues, reducing code debt and maintenance work. So teams often struggle to prioritize work in an organized way.

Therefore, an important concept in the Kanban process is limiting work in process by setting a WIP Limit. By limiting how much unfinished work is in progress, can reduce the time it takes an item to travel through the system. This also avoids problems caused by task switching and reduces the need to constantly re-prioritize items.

Setting a WIP Limit for both individuals and teams can help development teams move faster, reduce errors and collaborate more effectively.

3. Focus on Flow

When the first two principles of Kanban software development are in place, work flows freely. However, you need to focus your attention on interruptions in the flow.

These represent opportunities for additional visualization and process improvements. To assist flow, pull work through the pipeline. Don’t start any new work until a work item is completed. 

Blockers

Sometimes a work item cannot continue to flow through the pipeline due to an unexpected reason, so it becomes blocked. For example, the new project code which is ready for UAT, cannot be deployed to the test environment because of a system failure. Therefore, UAT cannot start. This work item would be marked as ‘Blocked’ on the Board until the issue is resolved. The number of days blocked would be recorded for reporting later. It is a good practice for blockers to be analysed in regular refinement sessions to identify any process improvements.

4. Continuous Improvement

Kanban requires constant monitoring and analysis to look for the next best way to improve development flow and remove waste. Conditions, resources and customer demands change over time, so it is always important to continually assess flow and WIP Limits and look for blockers and bottlenecks that can be removed.

Making small and meaningful changes will help the team perform more efficiently and effectively. 

Kanban Board and Cards

Kanban software development centers on the Kanban board, either a physical one in the office located in a prominent position for the whole team to view and access or as in recent times, a virtual one using software. The main purpose of the board is to create a shared understanding of value flow. However, the board does more than visualize workflow steps, it also highlights where bottlenecks are formed in the process.

To visualize your work, identify distinct steps or stages your work goes through as it moves from ‘To Do’ to ‘Done’. These will become columns on your board. Some boards may just have ‘To Do’, ‘In Progress’ and ‘Done’ columns. For a Kanban software development team, some examples of the columns created on the board include: ‘Design’, ‘Code’, ‘Unit Test’, ‘Code Review’, ‘UAT’ & ‘Prod’.

Each project or initiative should be allocated a horizontal swimlane. 

Pro-tip: If using a physical board, it is beneficial to use a magnetic one so magnets can be used as well as post it notes, which tend to fall off after a while. 

Kanban Cards

Every work item is visualized as a separate card placed on the Kanban board. Cards are moved from left to right to show progress and to help coordinate teams performing the work. The main purpose of the card is to give team members something to track as it moves throughout the workflow. This makes invisible work visible. 

Each card can contain critical information about the work item it represents. If a physical board is being used, then there is a limit of how much information can be displayed on each card. One way around this is for a team to also use issue tracking software like Jira and to raise a digital ticket too for each work item. This method allows for the meaty details to be contained in the Jira ticket and for the bare essentials details to be displayed on the card like Jira id, work item name and an estimate of effort. The advantage of tracking software is the history of a work item is stored for future reference and all team members can access and update the tickets.  

Another advantage is it allows Agile methodology to be performed so epics can be created to group work items, for example, in Jira, an epic is created for each project. Each epic can then be assigned a swimlane on the physical board. 

Avatars and Markers

There are different flavors of Kanban Boards and Cards. One flexible way is to assign Avatars for each team member often chosen by each individual and maybe as part of a theme. The avatars can be attached to magnets and are separate from the Kanban Cards. Each member only has one avatar as they can only work on one piece of work at a time. Their avatar is positioned on top of the card they are currently working on.

Magnetic Markers can also be used to highlight work on a card since the last stand up meeting i.e. a small green marker for any work completed and red markers for any blockers. These quickly allow the presenter at the stand up meetings to identify the progress or lack of progress and any blockers of work since the last stand up meeting for discussion. Once discussed, the green markers are removed from the cards, ready for today’s work to be tracked. 

Meetings

Once a board has been created, it becomes the centerpiece for at least two regular meetings:

  • Daily stand ups: Involves all team members, to discuss progress since the last stand up. These are usually scheduled in the mornings.
  • Refinement sessions: Involves all tech leads to discuss WIP Limits, board policies, blockers, bottlenecks and ‘stale’ work that has had no recent movement. These should be weekly or bi-weekly.

These meetings aim to focus on optimizing the flow that can help development teams stay productive and efficient by moving existing cards off the board. 

Summary

Kanban software development focuses on visualizing the entire project on boards in order to increase project transparency and collaboration between team members. The aim is to control and manage the flow of work, represented by Kanban cards so that the number of work entering the process matches those being completed.

Follow the four principles of the Kanban process for your team to consistently deliver high quality software.

Force Multiply Your Observability Stack with a Platform Thinking Strategy

Posted on by eugene evdokimov

Platform thinking is a term that has spread throughout the business and technology ecosystem. But what is platform thinking, and how can a platform strategy force multiply the observability capabilities of your team?

Platform thinking is an evolution from the traditional pipeline model. In this model, we have the provider/producer at one end and the consumer at the other, with value traveling in one direction. Platform thinking turns this on its head, allowing groups to derive value from each other regardless of whether they are the users or creators of the product.

In this article, we will unpack what platform thinking is, how it fits into the world of software engineering, and the ways in which using platform thinking can revolutionize the value of any observability stack.

Platform Thinking – A Simple Explanation

Traditionally, value is sent from the producer to the consumer and takes the form of the utility or benefit gained upon engagement with whatever the product/service happens to be in each case. Financial value obviously then travels back up the pipeline to the owner of said product/service, but this isn’t the kind of value we’re concerned with here.

It should go without saying that any successful change to a business model (be it technological or organizational) should lead to an increase in financial value. Otherwise, what would be the point in implementing it?

Platform thinking is certainly no exception to the end goal being profit, but the value we’re discussing here is a little more intangible. When we say ‘value’ we are referring to the means by which financial ends are achieved, rather than the ends themselves.

So How Does Platform Thinking Apply to Engineering?

The above explanation obviously makes a lot of sense if your curiosity about platform thinking stems from financial or business concerns. However, that’s probably not why you’re reading this. You want to know how platform thinking can be applied to your technical operations. 

It’s great that platform thinking could generate more revenue for your company or employer, but in your mind this is more of a convenient by-product of your main aim. You’ll be pleased to hear that the benefits of implementing a platform thinking approach to your operational processes will be felt by your engineers and analysts before they’re noticed by the company accountant. 

As we covered in the previous section, the value added by platform thinking comes in the enabling of collaboration and free movement of value between groups on the platform. Financial value then comes from the inevitable increase in productivity and quality of delivery that results.

Platform Thinking in a Technical Context

A technical ecosystem founded on platform thinking principles means that everybody involved, be they an individual engineer or an entire development team, has access to a shared stack that has been built upon by everybody else. 

Engineers work and build on a foundation of shared tooling which is continuously being honed and refined by their peers and colleagues. Anybody joining enters with access to a pre-built toolbox containing tools already tailored to suit the unique needs of the project. 

The productivity implications of this should go without saying, but they’re astronomical. Any engineer will be able to tell you that they spend a disproportionately large amount of their time on configuring and implementing tooling. Platform thinking can significantly reduce, or even remove entirely, the time spent on these activities.  

Observability- Why It’s Useful

Observability and monitoring are essential components of any technical ecosystem. Be it project-based development or BAU operations and system administration, a healthy observability stack is often the only thing between successful delivery and system wide outage. 

A well-executed observability solution prevents bottlenecks, preempts errors and bugs, and provides you with the visibility needed to ensure everything works as it should. Without observability being a high priority, troubleshooting and endless investigations of the logs to find the origin of errors will define your development lifecycle.

In our highly competitive technology market, the speed and efficiency observability enables can often be the difference between success and failure. Understandably your observability stack is something you’ll want to get right.

Freeing Yourself From Unicorns 

Here’s the thing – not everybody is an observability mastermind. The front-end JavaScript developer you hired to work on the UI of your app isn’t going to have the same level of observability knowledge as your back-end engineers or systems architects. It’s going to take them longer to implement observability tooling, as it’s not their natural forte. 

Rather than attempting to replace your front-end UI dev with a unicorn who understands both aesthetic design and systems functionality, you could instead implement a platform thinking strategy for your observability stack. 

Shared Strength & Relieved Pressure

In any project or team, the most skilled or experienced members often struggle to avoid becoming the primary resource upon which success rests. Engineers enjoy a challenge, and it’s not uncommon to find that the ambitious ones take more and more under their belt if it means a chance to get some more time with a new tool, language, or system.

This is a great quality, and one that should be applauded. However, it also means that when your superstar engineer is out for vacation or leaves for new horizons, the hole they leave behind can be catastrophic. This is especially true when the skills and knowledge they take with them are intrinsically linked to the functionality of your systems and processes.

By implementing a platform thinking approach your investment in your observability stack transforms it into a platform of functionality and centralized knowledge which all engineers involved can tap into. Not only does this reduce pressure on your strongest team members, it also means if they leave you don’t have to find a fabled unicorn to replace them.

A Platform Observability Approach

A platform thinking approach to the observability of your ecosystem enables every developer, engineer, analyst, and architect to contribute to and benefit from your observability stack.

Every participant will have access to pre-implemented tooling which is ready to integrate with their contributions. What’s more, when new technology is introduced, their deployment and configurations will be accessible so that others can implement the same without a substantial time investment.

This in turn significantly increases the productivity of everyone in your ecosystem. The front-end UI developers will be free to focus on front-end UI development. Your systems engineers and analysts can focus on new and creative ways to optimize instead of fixing errors caused by ineffective tracing or logging.

In short, a collectively owned observability platform enables everyone to focus on what they’re best at.

Force Multiplied Observability

The aggregate time saved and pooling of both resources and expertise will have benefits felt by everyone involved. From a system-wide perspective, it will also close up those blind spots caused by poor or inconsistent implementation of observability tools and solutions.  

You can loosely measure the efficacy of your observability stack by how often outages, bottlenecks, or major errors occur. If your observability stack is producing the intended results, then these will be few and far between. 

With a platform thinking strategy the efficacy of your observability stack is multiplied as many times as there are active participants. Every single contributor is also a beneficiary, and each one increases the range and strength of your stack’s system-wide visibility and effectiveness. Each new participant brings new improvements.

By creating your observability process with a platform thinking led approach you’ll find yourself in possession of a highly efficacious observability stack. Everybody in your ecosystem will benefit from access to the tools it contains, and productivity of your technical teams will leap to levels it has never seen before. 

Common Pitfalls in Maintaining Speed of Software Development

Posted on by eugene evdokimov

Google is known for giving developers difficult and quirky brain teasers during the hiring process. They’re specifically designed to filter out all but the top 1% of coders with the ability to solve complex programming problems.

In the 2013 film, The Internship, Owen Wilson and Vince Vaughan pit their wits against Google’s hiring manager for a chance to win one of Google’s coveted internships. They had to work out how to escape from a blender if they’d been shrunk down to the size of flies and put inside.  To this, Owen Wilson responded, “physics scares me.” He was not what you might call a 10x dev.

The Mythical 10x Dev

Techpedia defines a 10x dev as “an individual who is thought to be as productive as 10 others in his or her field. The 10x developer would produce 10 times the outcomes of other colleagues, in a production, engineering or software design environment.” It’s not hard surprising that every company wants to attract and hire these programmers.

A development team made of these mythical coding unicorns should be able to outperform average development teams by an order of magnitude, potentially leading to massive profits. There’s just one problem with building a business plan around this, it’s completely unreasonable. Regardless, the productivity of a software team is much more contingent on effective practices and culture than any individual’s abilities. Let’s explore this a bit.

Tar Pits of Code

IBM manager Fred Brooks painted a nightmare picture of how software development could go wrong in his essay The Tar Pit. Tar pits around the world contain the bodies of mammoths and sabre-toothed tigers who blundered in, only to find the tar was a death trap; the more fiercely they struggled to escape, the deeper they sank.

Brookes’ analogy was as pointed as it was chilling. An unavoidable by-product of large software projects is system complexity. He theorized that such projects are like tar pits and programmers working on them are in constant danger of being trapped within them. It doesn’t matter how quick they are at solving problems, the rot eventually sets in and development slows to a snail pace.

A Tale of Two Companies

About a year ago, I was entrenched in one of Brooks’ tar pits. It was a small software company who had built their codebase on a sturdy – if a little old fashioned – Java tech stack. On the business side they had some respectable clients, who paid them a lot of money. Not only were they keeping the lights on, there was cold beer in the fridge. Unfortunately, this picture of paradise crumbled as soon as anyone tried to do any actual coding. 

There was no documentation (the resident 10x devs hadn’t written any), and unit test coverage for the entire codebase was less than 5% (because those same 10x devs didn’t know how to do TDD). The codebase was a monolith application, so to test any changes – even one line of code – you had to build the entire application and deploy it.

To top it off there was only one development server. Whenever anyone wanted to deploy a code change, for any reason, they had to holler “deploy to dev” to the entire room and wait for the entire room to give the ok (who said coding wasn’t a spectator sport?).

As a result, productivity was low, very low. Developers with Masters degrees in computer science were writing ten lines of code a day. The rest of their time was spent reading code or reading the server logs. When I was at that company, I couldn’t program my way out of a wet paper bag.

In contrast to this previous experience, I’m now working at a start-up which markets healthcare apps. I’m working entirely remotely, becoming familiar with an entirely new system on the job. The only other guy I talk to is my boss, and communication channels are limited to Slack and Zoom. And I’m doing fine.

There’s no documentation yet but that doesn’t bother me. Firebase enables me to deploy my code with a single command while Node lets me fire it up on my laptop. Chrome dev tools gives me real-time feedback on what my system is doing, meaning I’ve got observability in spades.

What it Takes to Maintain Speed of Software Development

For me, the moral of the previous tale is that tooling and processes matter. Developers often think that their expert knowledge enables them to make even the most cumbersome tools pay dividends. The 2019 State of DevOps report busts this myth, showing that user-friendly tools and processes are just as important for pro devs as they are for end users.

Tooling Up

The fastest software teams use off-the-shelf systems that can be easily learned and require little customization. Developers in these teams can take their toolchain for granted and focus all their efforts on what Martin Fowler called “strategic” software. This is code that enhances the product and makes money for the company.

The explosion in serverless computing, containerisation, and automated pipelines has provided a plethora of commercially available tools for painless feature integration and deployment. State of DevOps findings show 92% of the highest performing software teams use automated build tools. In 2020, there is a wealth of CI/CD pipeline solutions, the most popular being Jenkins, Azure DevOps Services and CircleCI.

Accessible Knowledge Bases

The State of DevOps also found that easy internal and external search improved productivity. Internal search covers documentation, ticketing systems and easily navigable company codebases. External search includes Google and go-to sites like Stack Overflow. Good documentation and efficient project management frameworks, mediated by tools like Confluence and JIRA, increase developer productivity by over 70%.

Trust and Respect

A final point is psychological safety. Developers solve problems most effectively when they are working with people they can trust and respect. Like Thor and his hammer, a dev with the right tools can move the world.

Tricks to Being A Better Developer

Posted on by eugene evdokimov

The daily routine in the world of any Developer rarely ever reaches a point of tranquility. It takes real passion and drives to be able to seize each day, ready to take on the trials and tribulations that always find a way to pop up and take precedence over the usual workload. It barely even leaves most Developers any time to sharpen their skills.

Over an extended period of time, that often leads to Developers slowly losing their zest. That typically leads to a degree of laziness, which in turn leads to mistakes being made. The good news is that there are ways for a Developer to ensure efficiency on his part. Allow me to highlight some of them.

It’s About Having The Right Mindset…

Willingness: Test the Code

There is nothing wrong with a Developer testing his own code. I feel the need to state this because there are many out there who feel that testing should solely be in the hands of other teams. There is a gratifying element that comes from Developers that are able to at least assist with quality assurance. Bugs are obviously going to happen after all, and they are nothing to be embarrassed about.

Perspective: View End-Users as Customers

Developers must realize that their job isn’t to simply complete the tasks that are at hand. That’s because the end-users should be seen as customers. Customers are counting on the Developers to solve issues to make different aspects of their lives more manageable. Empathy plays a huge role here.

Open-mindedness: Open to Experiment

No one responds well to negativity. This is especially the case for a Developer that is quick to say “no” to projects or new ideas. Though it may seem like a way to back out of time-consuming commitments that may end up breaking, it also closes the door to creativity and innovation.

Dedication: In Oneself, the Team, and Towards the Product

Developers that aim to be more efficient are expected to have an innate need to learn more- whether through conferences, seminars, or other methods. They should feel the need to stay up-to-date on ever-evolving technologies. As such, they are also expected to be true team players. Communication skills play a crucial role when it comes to sharing insights, because it may change the way other team members are doing their tasks while working towards the common goal(s). Also, while developing products, it’s important to put security first while coding, for the sake of reducing the risk of cyber threats.

…And Being Conscientious.

There are bound to be bugs in the codebase, and there are many ways to get started on finding them with log data management software. However, it’s still in the best interest of everyone to keep some precautions in place while working on code.

Good Housekeeping

Code segments should be easy to read. Otherwise, they may be more prone to harbor bugs. So it’s important to keep the code clean and up-to-date, so it would actually be read more often instead of glossed over. On that note, it’s essential to be consistent with formatting, especially with indentation and spacing. Even outside of coding- with any form of documentation- consistency helps keep things easier on the eyes.

Sentence Structure

It saves time to spend some extra time writing comments in the code using complete sentences. Yes- with capital letters and punctuation. The same applies to spelling in the comments, and with identifiers. It saves time and energy for the next person that has to go through it.

Organization

Shortcuts rarely ever work out in the long haul, because it only creates confusion. This applies to many scenarios, such as when Programmers cut and paste code patterns (and modify key elements) to save time. That only leads to a mess to read. Another mess is when too much code is placed within a logical grouping of code, such as a function. Bottom line is that if there are more than 3 layers of indentation- there’s too much in that block. That’s just as much an offense as functions with long parameter lists.

The state of being in a positive mindset, coupled with conscientiousness is what all Developers should embrace in order to be more efficient on the job.