A friend of mine sent me a really fascinating book about architectural principles. While I initially found it to be almost foreign in the concepts it covers, slowly it became clear that the principles it contains do unlock the way forward for a current space I’m working in for software reuse.
When it comes to building software for charities, reusing code, designs and learning can be a real lifesaver. It saves time, money, and helps to reduce the risk of something going wrong. But, when you’re dealing with different charities, each with their own dialect and culture, it can be tricky to know where to start. With every brief and need being different it can be hard to see how reuse is even possible without being forced to start from scratch each time to deliver what every group wants.
Enter Christopher Alexander and his book: “The Timeless Way of Building”. Alexander was an architect, but his principles can be applied to software development too. There’s three key areas he unlocks (worth the read, but here’s the highlights I took)
1. Get to know the community and better understand the need
The idea is to start by really understanding the needs and desires of the people who will be using the software. You can do this by talking to them, surveying them, and really getting to know what they need.
2. Identify the patterns and see where reuse is possible
Once you’ve got a good idea of what’s needed, you can start creating a set of patterns to address those needs. This might include reusable code libraries, design patterns, and other components that can be used over and over again. However, it’s important to remember that every charity is different, so the patterns used will need to be customised to meet their specific needs. This is where experts come in - they can work with the charity to figure out what’s needed and how to make it happen.
3. Know that change is constant, and needs evolve
The final piece of the puzzle is to allow the project to evolve over time. This means constantly improving and refining the patterns used, based on feedback from users and changes within the charity. This helps to make sure that the software is always meeting the needs of the people who use it.
By following these principles, charities can save time and money, reduce risk, and get software that really meets their needs. Even though every charity is different, the patterns used to address their needs are often similar, so experts can use their knowledge to help other charities too. Not bad for ideas from an architecture book!
Digging deeper
So what are the challenges to this? how does this all work in practice? There’s three big areas that I think evolve the practice and bring in the nuance.
Why not work custom each time?
It’s often asked if the needs are clear why not start over and meet the exact need. In some cases that’s the right answer, we certainly do a lot of bespoke work at DEV - but the way we can meet the tight budgets we work to is to focus on learning and building on historical patterns we’ve seen before and adding to them.
Customising existing projects to create new ones is a great way to save time and money, and to reduce risk in software development for charities. Starting from scratch might seem like the best option if you want to deliver the exact original brief, but it can often be more time-consuming and expensive in the long run. By customising existing projects, you can build on what’s already been done and tailor it to meet the specific needs of the new project. This means that you’re not starting from scratch, but you’re also not just copying and pasting either - you’re taking the best of both worlds and creating something that’s truly unique.
Is customisation is still reuse?
If you have two similar projects that would each take 4 weeks to develop, it might seem like a good idea to work on them separately. However, it’s actually smarter to work on the second project after the first one is finished, and to build on what’s already been done. This way, you can save time and money, and create software that’s more likely to work well and meet the needs of the people who will be using it.
Customising existing projects is a great way to be more efficient because you can use the expertise of others instead of starting from scratch. You can build on what’s already been done and take advantage of what others have learned, which means that you can create better software in less time. This helps to reduce the risk and cost of software development for charities and increases the chances of success. By leveraging the expertise of others, you can create software that’s more efficient, more effective, and more likely to meet the needs of the charity and its users.
This is almost like the digital equivalent of upcycling.
So everything is just history repeating?
When software developers first tried to apply concepts like Christopher Alexander’s principles of building to software development, they do so with a digital rather than human mindset and attempted to make patterns for everything and aimed for “complete” reuse. However, this approach ultimately fails because one size rarely fits all in software development. (This is why there’s so many note taking apps available today!) It’s important to understand that Alexander’s approach was not about creating a monolithic set of patterns that can be applied to any project, but rather about learning the needs of individual communities and creating solutions that work for them but shortcutting toward GOOD solutions through recognition of patterns that exist in past GOOD designs.
Avoid the tempting trap of one standard to rule them all…
While patterns can be helpful in providing a starting point for development, they should not be used as a rigid set of rules to be followed without consideration for the unique needs of the project at hand. Instead, it’s important for digital leaders to take the time to learn about the specific context of the project, including the goals, constraints, and requirements of the community they are serving. This allows developers to create software that is tailored to the needs of the community and is more likely to be successful - basic user lead / needs lead design, right?!
Ultimately, Christopher Alexander’s timeless way of building is about creating solutions that work for people, and this applies to software development as well. By focusing on the needs of individual communities rather than trying to apply a one-size-fits-all approach, software developers can create software that is more efficient, effective, and ultimately more successful in meeting the needs of the communities they serve.
I get lots of energy from thinking about the work I’m involved in from this more abstract lens. If you’re thinking about reuse I’d love to get some feedback.