Understand Your Codebase to Innovate Faster

Rate this content
Bookmark

The transition from a monolithic architecture to a service based approach began a number of years ago. The advantage of a service based approach is to increase agility and shorten the build and release development cycle. And more recently the rise of micro frontends means that this approach not only encompasses backend application but also frontend development. However one side effect is increased complexity of the codebase. Resulting in challenges in terms of visibility into how components relate, who owns a component and the impact of activities on dependent components. This session will touch on these challenges and what is needed to maintain individual developer velocity.

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

Key areas include adopting open source software, iterative development approaches, leveraging cloud computing, integrating continuous integration and delivery, and utilizing service-based architecture to decouple application logic.

The approach has shifted from 'Big Bang' and waterfall methodologies to more iterative and agile methods. This allows for quicker development cycles, faster feedback from stakeholders, and the ability to make adjustments earlier in the application lifecycle.

Cloud computing removes the need to manage infrastructure and networking at a base level, allowing developers to access databases and middleware on demand, which simplifies configuration, deployment, and management tasks.

Continuous integration and delivery streamline the development process by allowing frequent software updates, enabling quicker testing and faster feedback on smaller changes, thereby reducing the scope of errors and issues in deployments.

Service-based architecture involves structuring applications as a collection of services, which improves encapsulation and reduces dependencies. This makes it easier to update and modify applications with minimal impact on other components.

The inner loop refers to the day-to-day tasks of individual developers, such as coding and debugging, while the outer loop encompasses broader team activities like releases and sprints focused on product iteration and delivery.

Minimizing interruptions involves providing developers with better tools and resources to understand and navigate codebases quickly, enabling them to maintain focus and efficiency in their workflow.

A deep understanding of the codebase allows developers to make accurate and efficient changes, reducing the time spent on reading and comprehending code, which is a major part of the development process according to industry studies.

Sourcegraph provides a universal search platform that enables developers to search across all their code repositories, facilitating better understanding and navigation of the codebase, which enhances productivity and accelerates development cycles.

Simon Waterer
Simon Waterer
19 min
24 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

We can improve developer efficiency by helping people understand code more effectively through open source software, iterative development, cloud infrastructure, continuous integration, and service-based architecture. The software development lifecycle consists of an outer loop focused on team efforts and an inner loop for individual developers. A universal search platform helps developers understand and search code, reducing the time spent on code comprehension. Code navigation and automation tools like Sourcegraph enable developers to navigate code, adhere to best practices, and automate changes across multiple repositories.

1. Introduction to Software Development

Short description:

We're here to answer your questions and to share your insights. Hello, everyone. My name's Simon Walter. I'm a software developer at Microsoft, and I'm here to tell you a little bit about how we can improve developer efficiency by helping people understand your code base more effectively. In terms of preparing for this talk, I've been into software development technology for some time. So here's my list of five. Your list may be different. So open source software, when I started in software development, essentially the APIs, the libraries you had available to you were essentially the ones that shipped with the operating system or came with a development tool or platform you'd invested in. And of course, there've been big changes in terms of how people go about building out software applications. So, we've moved to a more sort of iterative approach. And of course, the move to cloud where we're, you know, again, from a software perspective, you no longer have to worry about getting a hold of infrastructure or networking at sort of kind of a base level, where you can actually go out and get someone to deliver you a database service or provide middleware on demand without having to actually worry about how to configure or deploy or manage it. And obviously, then, in terms of, again, that's providing additional building blocks, excuse me, in terms of actually building and delivering software solutions. And the last two in terms of continuous integration, delivery, very sort of aligned to sort of agile development. And then finally, in terms of service-based architecture.

We're here to answer your questions and to share your insights.

Hello, everyone. My name's Simon Walter. I'm a software developer at Microsoft, and I'm here to tell you a little bit about how we can improve developer efficiency by helping people understand your code base more effectively.

In terms of preparing for this talk, I've been into software development technology for some time. and how they're relevant to software development, and how we actually deliver software applications, and how we can actually accelerate that process.

So here's my list of five. Your list may be different.

So open source software, when I started in software development, essentially the APIs, the libraries you had available to you were essentially the ones that shipped with the operating system or came with a development tool or platform you'd invested in. Now, we have libraries from, obviously, front-end. We're at a React conference, of course, to back-end in terms of providing databases, search tools, you know, many, many libraries, and perhaps the challenges in terms of deciding what library or framework you wish to use.

And of course, there've been big changes in terms of how people go about building out software applications. So, we've sort of gone away from sort of the kind of Big Bang approach or sort of the kind of waterfall type of methodologies where we capture our requirements, you know, which takes some time. You know, I worked for some time for a research company. We did a lot of work for large government organizations. We suspend huge sort of requirement documents that we had to either read or prepare.

So, we've moved to a more sort of iterative approach. We'll be sort of of smaller chunks in terms of the capabilities we want to deliver. And that's great because it allows us to essentially shrink that loop between building and delivering applications or capabilities, additional functions, and getting feedback from our, you know, stakeholders or clients, customers. So, a much more sort of iterative fast-paced approach.

So essentially, you know, allows us to actually correct direction much earlier in terms of the life cycle of a particular application or solution.

And of course, you know, the move to cloud where we're, you know, again, from a software perspective, you no longer have to worry about getting a hold of infrastructure or networking at sort of kind of a base level, where you can actually go out and get someone to deliver you a database service or provide middleware on demand without having to actually worry about how to configure or deploy or manage it. And obviously, then, in terms of, again, that's providing additional building blocks, excuse me, in terms of actually building and delivering software solutions.

And, you know, I'd perhaps sort of actually say there's a parallel between sort of cloud computing in some sense and open source software. Again, they're kind of fundamentally about sort of providing additional building blocks in terms of to allow software developers to sort of focus on their business problems, their business functions and capabilities that actually are where they can really add value to their customers.

And the last two in terms of continuous integration, delivery, very sort of aligned to sort of agile development. Again, the focus is in terms of testing, which you've kind of frequently delivering software or delivering and deploying software much more rapidly. Again, shrinking that loop, but also enabling us to actually test on with smaller changes, getting additional feedback more quickly. Ideally, when you do run into problems, that sort of setup of changes that you perhaps have to evaluate in terms of finding the root cause is smaller.

And then finally, in terms of service-based architecture.

2. Building Software and the Inner Loop

Short description:

From client-server to three-tier to multiservice applications, the goal is to improve encapsulation and decouple application logic. The software development lifecycle consists of an outer loop and an inner loop. The outer loop focuses on team efforts, while the inner loop is about individual developers and their tasks. The challenge is to minimize interruptions and maintain a fast flow in writing software.

So, it's a big change in terms of changes in terms of how we actually build software from an architectural standpoint, so from sort of client-server to three-tier to these multiservice type of applications. And again, where the goal is to improve or increase encapsulation and decouple application logic. So again, making it much easier potentially to make changes within our code because your changes have less impact or limited impact on other services, et cetera, because you're sort of sitting behind some sort of service-based API. And that's relevant in terms of front-end applications as well, where there's sort of perhaps a move to sort of allow people to create sort of micro front-end applications. Again, where we have a set of composable application components, which we can sort of stitch together very easily.

So, I'd say, obviously, all of these, changes, initiatives, obviously, have had a sort of an impact in terms of how fast, how quickly we can actually develop software. But if we actually sort of think about the software development lifecycle, it's not sort of one big loop. Many people sort of tend to think of it as essentially an outer loop and an inner loop. So, the outer loop is essentially the releases, the projects, the sprints that we're actually undertaking. So, it's more of a sort of a team effort in some sense. And I probably argue that in terms of the five changes we had above is whilst they definitely actually improve that sort of development lifecycle, they're more focused on that outer loop. Certainly in terms of you think about agile development, continuous delivery, I mean, that's their sort of square in terms of trying to improve the efficiency of that outer loop. But they have benefits in terms of that inner loop. And the inner loop is really around what you're doing as an individual developer. Okay, I have to make some change to you, I have to add a new capability. I have to fix some problem that appeared within our sort of a test suite. There's an incident and I have to investigate that, or I'm trying to sort of remove some form of technical debt within an application or set of services. So that's really the focus in terms of the actual sort of individual developers when you actually get to that sort of, you're actually writing the code, you're actually closer to the source of the code. And of course, what we all want to do is basically sort of ensure that we're as quick, we're as efficient as you can within that inner loop. Once we have a great understanding in terms of the task ahead of us, once we have such a kind of full context, we can really sort of, we understand the tech stack that perhaps dealing with at that point in time, we can be kind of very efficient, very productive. So we know exactly what we're doing. We can get away, we're in front of our ID and we can actually write our code, test it, iterate, and do it in a sort of a kind of very efficient manner. Obviously there are challenges in terms of, and I suppose the key challenges people face is essentially interruptions in terms of that flow where you have to sort of switch context. So obviously most organisations have you, we have sort of planned interruptions where we have meetings in terms of to update people on progress, but we may have interruptions in terms of people asking us questions, either members of our team asking us questions. And of course, there may be things we don't understand. We don't have full context. We don't have full understanding and we have to then go away and actually try and sort of fill in the gaps within our knowledge and in order to achieve the task we're looking at. And really it's in terms of, how can we actually minimise those interruptions so everybody sort of has context and sort of has that sort of kind of fast flow in terms of how they're writing software? So, you know, it's a cartoon that one of my colleagues pointed me out. So in terms of actually how we think about how we write software in terms of sort of talking about that in a flow. So, you know, obviously when we're writing software, we have some sort of blue-sky thinking.