You are a software developer, and you are well aware that there are plenty of terrible apps. Many are mediocre, and the decent, good and "plain and simple" ones, also fall by the wayside. But now ask yourself: How many apps do you consider exceptional and a benchmark in their field? You may find the number discouraging.
Discouraging... if you couldn't do anything about it. Look at it this way: The mobile solutions business is extremely competitive. With millions of applications available, it is a reality that every day the market becomes more saturated. But if you a developer and do your part well, the idea and execution of the business goes along with it; you have a unique opportunity to position yourself among the elite in this business sector. What should you do? Adopt strategies that bring you closer to that goal. Today we are going to look at five very specific ones.
1. Adopt best practices independent of the scope of the project.
Just because the initial scope is "short", and the initial application in its functions is "simple" to develop, we mustn't neglect good work. Many apps choke because they cannot grow at the pace of new requirements. Remember that every project well done adds value to the business and is much healthier -even mentally- when you generate a scalable architecture.
But be careful. The opposite case is also common: Overly robust projects that have been overthought end up being difficult and millimetric to maintain, as they require a lot of previous considerations and mastery for your new functionality or correction to be implemented. Having control of your codebase and its growth or simplification is indispensable.
One solution is to understand that the scope is constantly changing and creating an architecture that only considers the current business context means complicating the life and growth of your application. To this effect, always provide technical documentation to help you plan and have different perspectives of the construction of the application and its functionalities. Lean on your fellow developers, architects and analysts (if you have those people on your team) to generate and update the documents in the best way possible. The benefit of adopting a documentation habit will allow you to see potential limits and opportunities as the business evolves. You will see that the effort to keep it updated will pay off and help you maintain visibility into the health of your architecture!
2. Everything that is measured can be improved.
A principle very present in management, but sometimes forgotten in programming. To really take your application to the next level, ask yourself questions such as: Do I have defined good development practices? Do I know how complex my code base is? Do I know how my application performs beyond my own perception? Do I know how secure my application is? Questions like these will help you identify what your application lacks and how you can improve your IT solution.
Investing in a code analyzer to allow you to monitor performance is advisable. Hire a service that analyzes your binaries in search of vulnerabilities and implement useful analytics. All this will help you generate measurable metrics for your product. Having an informed and real context about the health of your application defends your work and gives certainty to the business unit. It lets you know what steps to take going forward and what to improve for future releases. In the end you will always know how much your product has matured over time.
3. Implement CI/CD continuous integration and delivery flows.
We've lived it. You've finished the development sprint, and you need to create a new version. You have to package your code and upload it to a testing platform, and then you have to upload the new build to the store. You have to iterate this process as many times as necessary for bug fixes, enhancements, scope changes and so on. It's time consuming. It's tedious. It eats up useful time. Let a machine do it. Invest time in it when possible and enjoy the development with less pressure.
Tip: I recommend that you and your team generate a delivery pipeline and have the stakeholder approve it. With this defined, negotiate the necessary time to gradually integrate these new processes into the development flow. Although it is not complex, it may require more effort if it is your first time in the world of integration.
4. Secure your code with tests.
Times have changed and QA is no longer solely responsible for ensuring product quality. And perhaps it never was. It is a shared responsibility.
Have a unit, UI and integration testing base where you can ensure that your code works as it should. Work on a service-based architecture where you can modularize tests and make them as granular as possible. Use design patterns that allow you to inject such tests; otherwise, it will be difficult to meet minimum coverage for your code.
Bonus: If your tests mature, you can include them as part of the CI/CD process I mentioned earlier, so that a new version is generated if and only if the tests are satisfactory. This provokes a confidence surplus in each deliverable and helps you verify common scenarios before they are reported to you in testing, or go to production without you noticing.
5. Think modular. Extrapolate your app.
A scenario like this is more common than you think: You've matured your application, you're happy, and suddenly "a new project" comes out. And since it's a totally different set of requirements... well, you and your team think you have to start from scratch.
It doesn't have to be that way if you modularize the components that make up an app.
Create packages of functionality that you can export. For example, the call to a REST API or a database manager are modules that are often repeated with little change and that you can reuse in all your current projects.
There is also the case where that new project is for the same client who wants the same design language. Well, wow! If you think about it, from the beginning you can develop generic parameterizable controls, and then produce packages to use them with little or no changes. The good thing about it? If there is any bug or error, you can correct the source and thus the common error of all apps. In the medium term, you will be able to concentrate more on meeting business objectives instead of reworking components and modules.
Everything mentioned about this can be worked on separately and gradually replaced in your projects.
Final Reflection
If you contemplate these strategies to achieve a sustainable architecture, and iterate them, you will see that naturally the evolution of your development cycle will lead you to deliver an application focused on the business and not on "the tediousness it takes to perform a development".
