Tactics and Strategies on Software Development: How To Reach Successful Software [Video]

The dream of any software engineering team and organization is to achieve success in their software and impact the business directly. However, the most challenging point is explaining how to achieve this success and get metrics. In this video, you'll learn more about this through strategy and tactics in software engineering.

When we talk about the metrics, it becomes even more challenging mainly because we look at the metrics focused on tech, such as the number of tasks, commits, more code, and deployment frequency. But delivering a version does not necessarily mean you're impacting the business. Let's start talking about this mistake: the passion for tech.

Technology as an End: The Most Significant and Current Mistake

As software engineers, we love what we do and have a huge passion, bringing us to the most trivial mistake: we became tech fanboys. Thus, we start with a tool instead of the focus on the solution. We can see it in Forbes's 16 Obstacles To A Successful Software Project, where the authors listed several topics. I'll put on highlight a few:

• Hyper-focused planning and design
• Unclear or undefined client expectations
• Unexpected complexities
• Poor collaboration between the product and engineering teams

“It is common for developers to deliver a product that doesn’t align with the client’s perceptions.”

When we check those points, it looks like a paradox, because we spend a lot of time planning while we don't deliver what the client wants, and poor collaboration with the product team. Fatally, we are offering complexity. Thus, what are you providing instead if you're spending time on what is not software? 

The unexpected complexity became a considerable enemy that is killing software productivity. We usually want to solve the problem and believe the focus is the new tool instead of understanding the context.

Every time it happens, I ask myself, "Did we forget what a software engineer is?"

What Is Software Engineering?

Talking about this definition, let's first understand the etymology: Engineering is from the Latin ingenium, meaning "cleverness," and ingeniare, meaning "to contrive, devise."

In building something to achieve a goal, we can use classic engineering with an aqueduct where reaching is not masonry but moving water to the city. 

Keeping with Roman history, we also can use military engineering with Caesar's Rhine Bridge, where Julius Cesar decided to build a bridge to cross an army of forty thousand soldiers in ten days.

It succeeded because it had strategy and tactics, where the strategy handled the goal and tactics care of getting things done. The goal was not to build a bridge but to cross the troops; its building was the way to archive it.

In software engineering, my favorite definition comes from Modern Software Engineering by David Farley, where:

"Software engineering is applying an empirical, scientific approach to finding efficient, economical solutions to practical problems in software."

Getting the goal is the first step, and an efficient, economical solution is what we want as software engineers. Julius Cesar wished to move the troops across the river. If the boats got cheaper, it would be the solution.

As a younger engineer, he uses the approach of strategy and tactics, where we can see the software architecture as the strategy and design as tactics. 

Indeed, we have several definitions of software architecture, and we don't want to spend time standardizing the term: unifying all those terms has a link with the goal. 

We can use it in the Fundamentals of Software Architecture with the second law of architecture: Why is more important than how, where we can remember the start with the why by Simon Sinek.

Strategy and Tactics

Combining strategy and tactics based on the context is crucial to achieving success where the root is the context. There is no silver bullet: we need to understand the context and then apply what it needs. We'll list this combination on six points: each item has a tactic and strategic perspective. 

Software Engineering

• Design
• Architecture

Code Design 

• Get done
• Code is not enough for software

DDD

• Entity, repository
• Bounded context, ubiquitous language

Documentation

• On Code, Changelog, README, Git commit message
• C4-model, Tech-radar, ADR, communication

Cloud

• The Twelve-Factor App
• Delegate what you don't want to focus

Test

• Unit test, coverage test, mutation testing
• Pyramid Test

Video

We'll listen briefly and provide more details in the video below: