Summary: Continuously improve your environment and design by doing improvements on the things slowing you down that are different than the actual task.
One thing every software developer notices is in time most software projects gets slower to implement new features and slower to develop.
This is because complexity rises as projects gets bigger and generally we don't spend much time on reducing this rising complexity.
Slowing development doesn't have to be the case though. If we give enough time to reduce complexity and be open to make changes to the application we can add features faster in time because this way we are developing an ecosystem that enables us doing that, instead of just adding more features.
Martin Fowler explains this as Design Stamina Hypothesis and here is the graph to show the visualise this:
Building an environment? Good design? Architecture?
Terminologies here a bit high level, let's make them more concrete. When we are adding features into our software project what we really want is the project help us add them faster. If we are struggling to find stuff in the project to make additions then we need to make improvements and changes.
A software project is like a book. If it is not very consistent across chapters we will have hard time writing more chapters. As an author doesn't start writing the book on the first page and finish the writing on the last page straight, we should also go back and make changes.
We can go faster as our design gets more consistent and our code flow gets smoother.
We should extract reusable pieces continuously, generalize the code, make them less dependent to the rest of the app as much as possible.
This also results in more reliable overall product with less defects.
Not even code, testing and integration automation process, deployment times and external dependencies are all places we can make improvements.
How to spot improvements? If something is taking your time while doing another thing, the first thing can be improved to be better.