Tactics and Strategies on Software Development: How To Reach Successful Software [Video]
Everyone wants to find success with software, but how? Learn tactics and strategies of a software engineer given during a presentation at Voxxed Bucharest 2023.
Join the DZone community and get the full member experience.Join For Free
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.
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.
- Get done
- Code is not enough for software
- Entity, repository
- Bounded context, ubiquitous language
- On Code, Changelog, README, Git commit message
- C4-model, Tech-radar, ADR, communication
- The Twelve-Factor App
- Delegate what you don't want to focus
- Unit test, coverage test, mutation testing
- Pyramid Test
We'll listen briefly and provide more details in the video below:
Opinions expressed by DZone contributors are their own.