Delivering Business Value: The Web Engineer’s Dilemma

Scoping Requirements and Estimating Effort

As web engineers, our primary goal is to deliver business value. However, to achieve this, we need to answer two critical questions: what do we need to deliver, and how do we know when the project is complete? To deliver business value, we must first scope out the requirements and convert them into a technical specification. This involves estimating the effort involved to approximate when the project will be finished.

// Example of scoping requirements
const requirements = [
  {
    id: 1,
    description: "Implement user authentication",
    effort: 3 // estimated effort in days
  },
  {
    id: 2,
    description: "Develop dashboard feature",
    effort: 5 // estimated effort in days
  }
];

The Consequences of Poor Estimation

Estimating is a fallible process, and we’ve all had experiences where our initial estimates were way off. When we underestimate the effort required, pressure mounts on the deadline. To meet the deadline, we often take shortcuts, copying and pasting code snippets, duplicating components, and creating quick fixes.

// Example of copied and pasted code
function getUserData() {
  // duplicated code
}

function getDashboardData() {
  // duplicated code
}

While this approach may seem effective in the short term, it leads to technical debt, making our codebase complicated and unmaintainable.

The Accumulation of Technical Debt

Technical debt is unavoidable, especially in the fast-paced front-end world. As we rush to deliver features, we accumulate debt that will be painful to resolve in the long term. Our codebase grows, and we spend more time maintaining existing code than working on new features.

• Technical debt symptoms:
  • Code duplication
  • Tight coupling between components
  • Lack of documentation

The Importance of Reducing Technical Debt

While we can’t avoid technical debt altogether, we can take steps to reduce it. By implementing design systems, unifying our workflow, and improving communication between design and development teams, we can reduce technical debt and deliver business value.

/* Example of a design system component */
.button {
  background-color: #333;
  color: #fff;
  padding: 10px 20px;
  border: none;
  border-radius: 5px;
  cursor: pointer;
}

A Success Story: Implementing a Design System

I recall a project where we migrated from a legacy Ruby on Rails application to a microservice architecture with multiple React applications. We implemented a design system, unifying our workflow and reducing technical debt. Although it was a challenging process, the results were worth it. We saved time, improved communication between teams, and delivered business value.

The Takeaway

Implementing a design system may seem like a blocker in the short term, but it pays off in the long term. By reducing technical debt, we can speed up front-end development, improve communication between teams, and deliver business value. As web engineers, it’s essential to prioritize reducing technical debt to achieve our primary goal of delivering business value.

Learn more about design systems and how they can help reduce technical debt