Software Size
When building software, you are in a constant state of decision-making. Size is involved in plenty of these critical decisions. That is why software size matters. In this post we will make a small introduction to these elements and cover them in more detail in future tech blog-pieces.
Every time we are making a decision, we should have the following sentence in our mind:
We are people creating software for a purpose in a context.
- People first. In 2020, you cannot build a software product without the right people. Also, your process should be there to help people.
- We create software for a purpose ,the why is essential.
- Don’t forget the context : businesses should share everything with their teams, for those teams will work much better when they understand the situation and goals.
The fundamental things to decide are: What to do or how to do it (process, solution and delivery) and by whom. Some general advice: decide things together. You know what to do, how to do it, and you can build teams around that idea. Sometimes you have the team and you know what to do, so arrange the ways you will work to match your team composition accordingly. These decisions are not independent.
Who will develop the software – Conway’s law
Your organization should be a direct representation of the software you are going to build. Pay attention to how to organize everything from the very beginning. Don’t create departments in your organization, silos of information or groups of people that have different responsibilities, and who might end up blaming each other. You can have independent teams working in different domains, but they should have good communication or even share some framework. Be Agile and trust your people and your teams to solve all the problems. Trust is key in building software.
Size of the software team
Assuming that you are working in an Agile mindset, you have a T-Shaped team and you follow some Scrum recommendations, you will have 7 (+/- 2) people in your team. They will cover all of the roles involved in software development and, don’t forget: the product owner is part of the team. The most important thing to remember here is “Brooks’ Law: Communication Overhead”.
Also, the team should have all the tools needed to gather requirements, build the software properly, test and, ideally, deploy and release it to production. Ownership is another pillar in good software environments.
What to do
Divide and conquer: Both, too small and too big are equally a problem.
Size of the Domains – When working in most parts of a product, it is critical that you prepare all of your organization to work under the concept of domains. It will help you scale your team, create independent chunks of work, and will guide the technical implementation of your product. DDD is a well known method of achieving this. It will help you split your bounded contexts and delineate the boundaries and surface areas between them. The nature of those surface areas will lead to different technical implementations that will guide your software architecture and infrastructure. We will talk about how to solve circular references between domains, as it’s typically the major pain-point when doing this kind of approach.
Size of the work to do
You usually organize the work in Epics, Features and User stories. This is one of the most important sizings that will be involved in software development. You should have small user stories and they should be as independent as possible. They also have to be meaningful. If you reduce the size too much, you will create an overhead in the process and the team efficiency will be impacted. As always, involve the full team in the refinement of the stories and use techniques to split the work into small chunks. There are a lot of options about which we will talk about in a future tech blog entry.
Definition and QA
Remember that it’s good practice to use BDD in a language like Gherkin, for task-definitions. Also, be aware of the testing aspect of the story. If your organization isn’t mature enough, you won’t have testing automation in place, and using Gherkin definitions will help you to move to the right place in the future. If you are using TDD, you will have all the tests ready before starting to code. Finally, the user stories will have a clear test plan, which could modify the QA regression while you don’t have all the automation in place.
A couple of important things in the user stories to remember: Definition of ready and definition of done.When to do it? Remember always to organize your work in small increments that can be delivered gradually to add business value. Quick feedback and reducing the time to market is key.
How to do it
Process – Listen to the team
Size of the software sprints – If you choose Scrum, you will need to decide the size of the sprints. From 1 to 4 weeks, usually. There isn’t a magic number and it depends on the type of software that you are building, as well as the size of the product increment. Remember that if you decide to have a QA engineer inside of your team, she/he will be exposed to potential bottlenecks at the end of your sprints. You could avoid this scenario, as some companies are doing, by, for instance, removing this QA role and letting the engineers be responsible for the quality of their work. TDD could be another solution, as well as letting everyone in the team be a QA.
Size of the ceremonies – Try to reduce the number of meetings and their duration. Try to reduce the amount of information in every meeting and try to have everyone involved. It’s important to have all the context to build proper software. Again, why is very important. If your group is big, it’s very important to be effective in terms of communication (concise and accurate). With an agile mindset, you should adapt your process iteratively, improving with every loop.
Conclusion
All of this is very important but trust, ownership, sharing all the context and aligning your organization with your software principles are the key pillars to success.
Do you know how big your software modules should be? Should you go with microservices? A monolith? Should you go with small serverless functions? Can you build something and decide later?
Do You Need Help Designing Your Optimization Strategy?
You’ve come to the right place. Our in-house experts have extensive experience and in-depth knowledge of software optimization and modernization processes. Whether you need a complete roadmap for your entire strategy or multiple smaller product roadmaps, we can help you design the best solutions for your DevOps team.
For more information, read about our technology consulting services or check out our team augmentation services for a seamless collaboration!
