Nowadays we hear about sustainability a lot and almost in every field, computer science is no exception, but how can we develop software in a sustainable manner?! Is it just a hot trend and a keyword that you just need to include in your landing page or is that really an important topic that needs to be converted into a mindset? In this article we are going to talk about sustainability in web and mobile development.
How Green is your Software?
On its own, software doesn’t consume energy or emit any harmful discharge. The problem lies in the way software is developed for use and then in the way it is used. From the laws of software evolution by Manny Lehman, we know software goes through continuous adaptions which can be best described as evolution. Creating software is not enough, nor is it the most challenging part, the continuous adaptations to ever-changing clients is the main challenge of our software. The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand.
So for software, "sustainable" actually means "evolvable". The ISO standard 25010 for software product quality uses the term "maintainable" exactly for this quality characteristic of being easy to change.
Instead of building for the short-term and hoping for the best long-term we should choose to embrace the responsibility we have in evolving our software long-term. We know the clients will change, we know regulation will change, we know the environment they operate in will change and we use that knowledge today by building software for the long-term. That definitely needs a solid foundation that allows the software to evolve over time.
Both Sustainable Software Development and Extreme Programming deal with the tension of dates and features by asking “how do we reduce scope?” and “what should be done first?” In other words, developer happiness and sustainability is achieved by prioritizing the work. Under difficult conditions, developers have to struggle with deadlines that force them to program hacks.
Over time, maintenance is changing more and more from structured programming to defensive programming. Developers start writing code that they know is bad from an architectural point of view. The code becomes more complex and the team accumulates technical debt. Maintenance costs increase and enhancements lead to more side effects. The result is poor architecture that drives up development costs.
If the technical debt is low, the maintenance developers will find their way around the system easily. They can fix bugs quickly and easily and have no problems making cost-effective extensions. But how do we get into this promised land of architectures with reduced technical debt? We have to borrow the best practices from Kanban, Scrum and eXtreme Programming, like focusing on Continuous Delivery, Test Driven Development and Pair Programming.
Beside writing code and developing new features in a sustainable manner, which we are going to discuss in this article, having a sustainable organization/team is also equally important. You have to continuously improve the team and people working on the software and create a sustainable organization that fosters continuous improvement, scales well and provides sufficient capacity. We can talk about it more in a future article.
Technical Debt
As we develop software, most of the times we create some kind of technical debt, also known as design debt or code debt, that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
As with monetary debt, if technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes. Unaddressed technical debt increases software entropy. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) is required to move projects forward.
As a change is started on a codebase, there is often the need to make other coordinated changes in other parts of the codebase or documentation. Changes required that are not completed are considered debt, and until paid, will incur interest on top of interest, making it cumbersome to build a project.
The common types of tech debt are:
- Refactoring bad code
- Updating old libraries
- Removing dead code
- Incorrect naming and log messages
- Introducing better tools and techniques
- Cleaning up code not following agreed standards
- Fixing technical defects
- Tightly coupled components
- Last minute specification changes
- Many more…
When we talk about technical debt, you will also hear about other terms like Code smell, Big ball of mud, Spaghetti code, Software rot, Shotgun surgery, Bus factor, Escalation of commitment, Software entropy and Over-engineering.
Automated Testing
Automated testing is the application of software tools to automate a human-driven manual process of reviewing and validating a software product. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually.
Writing some automated tests should be standard in most cases when working on features. However, even if you follow that practice you are likely to end up with areas that will benefit from some concentrated testing effort.
Test automation, mostly using unit testing, is a key feature of extreme programming and agile software development, where it is known as test-driven development (TDD) or test-first development. Unit tests can be written to define the functionality before the code is written. However, these unit tests evolve and are extended as coding progresses, issues are discovered and the code is subjected to refactoring. Only when all the tests for all the demanded features pass is the code considered complete.
Testability
One thing is writing automated tests, the other is making your application more testable. If the testability of the software artifact is high, then finding faults in the system (if it has any) by means of testing is easier. Adding logs, improving APIs, refactoring code may result in an application that is much easier to test.
This is a prime example of sustainability, as it is doing work that will benefit the project moving forward, by making it easier and faster to write robust tests.
The correlation of 'testability' to good design can be observed by seeing that code that has weak cohesion, tight coupling, redundancy and lack of encapsulation is difficult to test.
Monitoring
Making application easy to support is a very important aspect of sustainable software development. It is difficult to focus on creating new features when the team’s focus is constantly on firefighting issues or false-alarms that arise when running the application in production.
Common ideas for improved monitoring and support are:
- Introducing a robust monitoring solution that covers application performance, user activity monitoring, network and system monitoring, event management and ..
- Creating monitoring dashboards
- Adding alerting capability
- Improving logs created by the system
- Improved health checks
- Creating a reliable, resilient architecture
Documentation
Documentation is sometimes seen as a “dirty word” by developers. The problem is that often, there is quite a lot of documentation being created with a considerable effort that is never used/maintained/looked at again.
The key here is focusing on creating useful and valuable documentation. Things such as:
- Onboarding documentation for new joiners
- High-level architectural diagrams
- List of services and their descriptions
- Coding standards
- Development practices
- Other documentation that is deemed useful
I do not advocate creating documentation for the sake of documentation, but there are cases where some can be really useful. Ultimately it is up to the team and other stakeholders to decide what is and what is not useful.
Tooling
Having a good development experience is often as important for sustainability as having a good codebase. With that in mind making sure that you are using the right tools becomes an important part of delivering the project.
Sometimes the tools and techniques that you use will become partly or totally obsolete, after releasing your software, if you are lucky enough that it won’t happen during your dev cycle. Big companies like Google can always start the day by saying a previously popular tool is now obsolete! We all know the story of the AngularJS lib. You can check the killedbygoogle.com website to see the list of all the tools that google has unplugged or is going to do so.
The web is changing each day. A solution, a tool or a method that is hip today, can easily be less desired six months later. So you better choose the more sustainable tools. If there is a huge hype around a new tool or technique, it doesn’t mean that its going to last for long!
Making changes in a software that is developed using deprecated tools is not an easy task! Sometimes you have to create patches for the new components and libraries that you are going to use, because they are not compatible with your existing tools. It’s obvious that after a while you get into defensive programming to defer any new change.
Spending time on your CI/CD, communication tools, even making your project more IDE friendly can all be worthwhile efforts.
Conclusion
Sustainable software development is a mindset (principles) and an accompanying set of practices that enable a team to achieve and maintain an optimal development pace indefinitely.
Sustainable software development is about planning, avoiding unnecessary work and building long-lasting solutions. It is about efficiency and balancing the needs of the short and long term. It does not mean throwing away all the legacy systems, but looking closely at the current state and what it consists of. Digital sustainability is about maintaining functioning systems and operating models and to boost them with more supportive systems and integrations.
Digital Sustainability in software development means less redundant code, more reusability, and more accurate business solutions.
Abiding by the laws of software evolution and embracing change is not easy, but we have developed a method to make our team responsible for long-term happy clients and everything that it entails and not just feature development.