Let’s continue the series about technical strategy. In the first blog post, I’ve detailed what technical strategy is and why it is important. In this article, you will find more about what the technical strategy should contain for a particular product.
A few things need to be well defined, clearly communicated and constantly repeated. Before we dive in, a caveat: some of them apply to certain phases in the lifetime of a product. A sole developer can keep the strategy in her head; however, when the product has 10000 lines of code and 10 developers, that’s no longer attainable. Things get much more difficult when 30 teams of 9 people work on the same product. Detailing all possible needs for all possible contexts is impossible. I will instead give a few examples from my experience working with Mozaic Works customers.
This article contains information about: software architecture, testing strategy, configuration management strategy, and code quality strategy.
Software Architecture
The software architecture fits our “strategy explanation” perfectly. It is usually difficult to change, and all developers have to live with it for the lifetime of the product.
When we talk about software architecture, we look at a few areas:
- High-level organization (modules, deployment, etc.)
- Communication between modules
- Consistent patterns used in all modules
- Cross-functional requirements like scalability, performance, security, reliability, logging and exception handling etc.
The most common goals of software architecture are:
- A working application that does what’s required
- That runs for as long as possible
- Reduced development and deployment costs
Software architecture is influenced by things such as availability of developers, budget, and type of application, among other things.
Testing strategy
Testing strategy refers to:
- what types of automated tests are used
- who writes them
- when they are executed
- what areas are covered by manual testing
- who does the manual testing
- when manual testing is performed
The purpose of the strategy is usually to have an efficient testing process that can be used for a long period of time. The improvements we’re looking for are:
- reduced time spent on repetitive work (manual testing based on a plan)
- reduced number of regressions
- reduced number of issues reported by users
- as little time spent writing automated tests as possible
When we help our customers create the technical strategy, we start from the pyramid of tests, explain each type of test, sometimes write a few examples, and then write a document that describes all the above. This often includes examples from their production code. Sometimes, we make a presentation of the strategy to the whole team or help the leaders prepare that presentation. In other cases, we help with the execution of the strategy by training or mentoring developers and testers on automated testing.
Configuration management strategy
The configuration management strategy refers to:
- what source control system is used
- when branches are created and by whom
- how branches are named
- when branches are merged and by whom
- what branches are deployed
- who deploys them
- when they are deployed
- when a version is tagged and by whom
- if there’s a code freeze period, when it starts and when it ends
- what is the connection between branches, tags and deployed versions of the application
The purpose of the configuration management strategy is to have a seamless development process and a very clear connection between deployed versions and source code commits. We’re looking for things like:
- reduce time spent merging and merge conflicts
- keep the number of branches under control
- maintain the branches as short-lived as possible to reduce inventory and merge conflicts
- know what each branch is for
- know exactly where to look when a bug is reported in an older version
The source control system, the number of teams, the overall development process, and many other factors lead to very different strategies. Like the previous one, it doesn’t live in a vacuum; it has a strong connection with things like continuous integration, automated testing, product versioning, etc.
Code quality strategy
Everyone needs code quality, at least declaratively, but what does that mean? How do you ensure it? Who is responsible for it? How do you measure it?
From all the examples, this is the fuzziest and the highest variability. Depending on the customers’ context, we’ve recommended one or more of the following:
- Coding guidelines: a 2-page document with the most important things to do and not to do when writing code
- Clean code: following rules detailed by Robert C. Martin in the book with the same name
- Exception and logging policy: a max. 5-page document detailing what types of errors can appear in the application, how they are treated, what is logged and how
- Code review policy: who does code reviews and when, how issues are corrected and when they are analyzed
- Design principles: 4 principles of simple design, SOLID and/or the UNIX design principles
- Design guidelines: what other things should a developer think of when designing the code, and how to check them
- Design patterns: starting from the Gang of Four patterns, going into enterprise integration patterns and other sets
- Using TDD: an incremental software design process, well fit for fast-moving development
The list is incomplete yet can look overwhelming. It’s important to understand that not all these things need to have strong rules. We love all these practices at Mozaic Works and apply them for our products at MozaicLabs. But the customers’ needs are more important than our preferences.
Therefore, our advice is to add only the ones that solve a business problem. For example, if you don’t have a lot of bugs, yet development moves too slow, refactoring and TDD might help you. If you find a lot of issues, bug root-cause analysis, code review, and pair programming are quick wins.
How do you apply the technical strategy for a specific product? What is your experience? Share with us lessons learned in a comment.
Check below the other 2 articles from this series:
Product strategy: technical strategy in practice (I) – what it is technical strategy and why is it important
Product strategy: technical strategy in practice (III)– who creates the technical strategy
