DEV Community: Victor Akpan

Trade-offs, no absolutes

Victor Akpan — Tue, 11 Aug 2020 04:29:40 +0000

IT ecosystem is in a state of continuous change. A decade ago containerization tools like docker and kubernetes didn't exist. Today, you can't talk about fault-tolerant, availability and scalability without considering these tools. Chances are 10 years from now a new set of tools will emerge. There are no absolutes anymore, every technical decision has its trade-offs.

Merriam-Webster dictionary defines trade-offs as "1: a balancing of factors all of which are not attainable at the same time. 2: a giving up of one thing in return for another". Technical managers, architects and engineers have a duty to question every design decision, consider its trade-offs and how these trade-offs align to the requirements of a project.

For example, you are tasked with selecting a programming language for a new project. Your first instinct might be your favorite language or one you are comfortable with. Given the impact a programming language choice can have on a project, we have to set aside our feelings. Selecting a programming language for a project depends on a number of factors such as:

Client's requirement (some clients explicitly specify which language to use, but you can advise on the trade-offs)
Cost of hiring new talents
Learning curve
Functional vs OOP
Strong static typing
Isomorphism
Interface support
Ease of refactoring
Explicitly defined data structures
General readability
Third party libraries

As engineers, it is easy to become attached to a particular technology or approach, especially if this approach was implemented successfully in your previous projects. But we have a responsibility to humbly assess the good, bad and ugly of every choice we make. Everything is a trade-off, no absolutes.

Basic concept of Docker Image and Containers

Victor Akpan — Tue, 05 May 2020 03:27:58 +0000

I have created this image to explain the basic concept surrounding Docker images and containers. I hope you find it informative.

Scrum 101

Victor Akpan — Mon, 20 Apr 2020 03:24:40 +0000

Almost everyone I've worked with has heard of Scrum or Agile way of working. Some have adopted Scrum partly (ScrumBut), while others have done so fully by adhering to the rules of Scrum.

Scrum is a framework, not a process or technique

It is common in the workplace to see the application of Scrum as a process alongside other agile or traditional techniques. I do not have the metrics to show the success and failure rates of this pattern. Nevertheless, I've had a first-hand experience on (ScrumBut) projects, and I can say that these projects failed or were delivered with low quality.

Let's say your organization is agile and has adopted several agile methods, for example TDD, Kanban, XP, Lean, etc. These agile methodologies can run smoothly inside Scrum. Scrum is like a container for running processes or techniques, its events allow you to use techniques within it, provided business value is created.

Scrum is immutable

Unfortunately, this is very common today, you hear things like "we use Scrum but...". Another example is a Scrum Team with titles like "Project Manager", "Architect", "Lead Developer" etc. This violates the rules and values, the glue that bind Scrum components together.

Scrum is immutable, that means its values and rules should remain unchanged. It should not be used in part. To reap the full benefit of Scrum, it is recommended that it is adopted fully. You either use Scrum in full (properly) or not at all.

"The truth will set you free. But first, it will piss you off." - Gloria Steinem.

While Scrum respects domain expertise, there can be ONLY 3 roles in a Scrum Team: The Product Owner, Scrum Master and Development Team (Member). Anyone in a Scrum Team who is not the Product Owner, or a Scrum Master is a Member (software developer, Business Analyst, Architect etc.) irrespective of their expertise and title in the organization. No Leads, Managers, Architects, Testers and what have you. The Development Team works together as a cross-functional unit. One for all, all for one.

Scrum does not take your titles away.

Within an organization, your title or expertise is part of your identification and Scrum is fine with that. But within a Scrum Team, you are a Product Owner, Scrum Master or a member of the Development Team. Nothing more, nothing less.

And that my friend is Scrum 101.
Let's Scrum on together and build great products and people.