Why Software Developers Need To Adopt a Systems Thinker’s Mindset
Rakia Ben Sassi
Freelance Senior Software Engineer | Google Developer Expert (Angular) | Speaker & Content Creator
Let go of raw coding skills to understand the bigger picture
I share content about engineering, technology, and leadership for a community of smart, curious people ????. Join my newsletter and subscribe to my YouTube channel for more updates and tech insights.
There is one expression that I particularly love: Zoom out.
I love to zoom out because it allows me to see the big picture and determine my position on the whole. Without this action, I feel like I’m lacking vision and orientation, and I’m kind of lost.
I don’t know what “zoom out” means for you, but for me, it means learning different technologies and paradigms than the ones I’m using, understanding the business side of the software I’m implementing, or even identifying patterns in one discipline and apply them in different contexts.
One way to “zoom out” is to shift our thinking from?binary to spectrum . But there is another one, called Systems Thinking, which is used in different fields including software development. When applying systems thinking, you get a new perspective on how to build software projects, as well as an opportunity to reflect on your?job ?from a different angle.
In the next section, we’ll tackle this concept, and to avoid getting bogged down in theory, we’ll work through a list of examples of how to use systems thinking in a typical software development team.
What is Systems Thinking?
In a nutshell, systems thinking is a philosophy of viewing the world as a collection of complex pieces. In software development, systems thinking is about understanding and building software together with your team in order to achieve business outcomes that are in alignment with what the organization wants to achieve.
When planning a project with this mindset, you analyze both technology and business aspects while considering their relationships.?Systems thinking’s main objective is not to follow a routine but to address problems holistically as well as effectively.
If we use a car metaphor, we could say that:
It’s unreasonable to be successful in one part without being familiar with the other.
Why Use Systems Thinking?
Here are some reasons you should use systems thinking as a software developer:
1. Be mindful of what’s going on in the industry at large
If you’re not doing systems thinking regularly, you might not see?trends ?and?patterns ?that others will notice and use to their advantage.
2. Consider the future state of things
Looking at things from a long-term perspective can lead you to make better decisions today with respect to your ongoing projects and even the future ones. When you consider the implications of these decisions, you’re able to project into tomorrow without having all the answers yet.
3. Free yourself from dogmas and embrace change
Being aware of the different situations or contexts in which change can take place in your software development process allows you to prepare for it. You can easily recognize a situation when feedback is required, or when there is a need to adopt a new paradigm, even a new technology.
4. Have better relationships with your colleagues
If you are able to understand and talk about different aspects of business and technology, you will build respectful relationships with other members of your team.
5. Get on time and on budget
Systems thinking enables you to plan your projects by considering factors such as changing circumstances, attitudes towards change, and different people’s perceptions of the project. This will prepare you for the long haul.
6. Get more insights to tackle problems
When considering aspects holistically, you will articulate problems in new ways. The?range of choices available will expand, and it will be easier to come up with good solutions.
Here is an example from “3 Tips To Solve Coding Problems Like an Expert ”:
领英推荐
Peter Senge’s 11 Laws of Systems Thinking
In his book, “The Fifth Discipline: The Art and Practice of the Learning Organization ,” Peter Senge has focused on problem-solving using systems thinking. He presented a set of approaches and methods that can be applied to any field that is rooted in human relationships. In the book, Peter Senge talked about 11 laws that we can use collectively to?solve problems ?across different contexts:
Let’s take a look at some examples of how these laws manifest in the software development realm:
Law 1: Today’s problems come from yesterday’s solutions
This law remembers us of technical debts which result from choosing easy, quick solutions instead of better approaches that would take longer.
Law 5: The cure can be worse than the disease
Law 5 refers to a hotfix or an implementation of a new feature that causes a regression in other corners of your application.
Law 6: Faster is slower
Of course, you know it, and you are not alone. Each one of us has worked on a project where 20% of the implementation time was spent on finishing all the requirements and 80% of it was consumed by bug fixes, or?performance ?optimization resulting from unclean and spaghetti code or other flaws.
Law 9:?You can have your cake and eat it too — but not all at once
This law means “you cannot simultaneously retain your cake and eat it.” In other words, you cannot expect to have two incompatible things.
As an example of this: you can imagine a customer who wants to optimize his web app performance and increase its?accessibility ?at the same time. He asked you to offer the user the possibility to open an edit dialog by:
Can you guess what’s wrong here?
Whenever you add more keyboard listeners, you should expect a decrease in?performance . So more keyboard listeners and better performance could be considered as two incompatible requirements.
Law 10: Dividing an elephant in half does not produce two small elephants
“Elephant” is not just any old term; it’s a metaphor to describe something that appears complex, but in reality contains a lot of individual parts and relationships between them. Law 10 means that a piece of software that is built in a given context can’t be separated that easily.
Let’s say that you have implemented a REST API or a library that is used later by different projects within your company. After a few months, you’ve noticed that you need to restructure the source code, give some methods better names, and carry on other changes.
Whenever you want to update your library, you have to avoid a regression in other projects; you need to be aware of how this update could affect other systems. Even if there is a method that you want to delete — as a clean-up —?and it’s used in an external application, you have to decorate it as?deprecated without removing it.
Final Thought
No matter what industry you are in, some problems can be solved better by zooming out and considering all related factors before diving into details.
In order to be effective, we need to understand our role in the big picture. How do I relate to everything else? How is what I’m doing affecting others? This will allow us to understand the landscape and determine the right technology and products to build.
With this in mind, I leave you with a quote that I hope will inspire you:
“The discipline of systems thinking is more than just a collection of tools and methods — it’s also an underlying philosophy. Many beginners are attracted to the tools […] in hopes that these tools will help them deal with persistent business problems. But systems thinking is also a sensitivity to the circular nature of the world we live in.” —?Systems Thinking: What, Why, When, Where, and How
Originally published at?Better Programming .
Did you know?
References
[1]?Systems Thinking