Develop fast, release, learn, repeat. That’s essentially the (not-so-secret) innovation formula, right? Most of us spend our time enhancing the products we have already released. We want to be innovative, releasing new features with the velocity of an unencumbered startup. Yet, we also have customers with quality expectations we need to meet. Guidance on shortening release cycles often centers on adopting agile (or similar) development methodologies. But most companies are already there.

Over the recent years, software development organizations have seen a major shift in where they build and run their applications. Teams have transitioned from building applications that run exclusively on-prem to microservices applications that are built to run natively in the cloud. This shift gives businesses more flexibility as well as quick and easy access to enterprise services without the need to host costly applications and infrastructure.

Looking at modern software development practices, most of them aim at maximizing the output of your team and the quality of your software. Unless you’ve been living under a rock for the past 20 years you know of the agile development methodology and you’ve probably heard about the lean methodology. Both of these methodologies can be differentiated by a few factors, but they are pretty similar - they aim at delivering fast and to the point.

As the world keeps spinning and technology keeps progressing ever-further, a lot of focus is being put on optimizing productivity. However, there is an aspect that is being overlooked: adaptivity. Being adaptive as an organization has become critical. It’s not just about your organization, but about helping your clients to be fluent and adaptive as well. In our experience, this means helping the user to get the best experience possible.

Previously in our hypergrowth series, we spoke about the business and cultural aspects of hypergrowth. We highlighted guidelines such as focusing on sales enablement and empowering your employees as a means to ensure that your company culture can be sustained as your business grows by 40% year over year.

As new advances in software development have allowed developers to increase their velocity and push out new software at ever increasing speeds, one less measured metric is software understandability. Although it probably seems obvious, when building new software the goal should always be to build software that is as simple and easy to understand as possible.

As most developers will agree, writing code is oftentimes, if not always, easier than debugging. As a simple definition, debugging is the process of understanding what is going on in your code. When speaking in terms of Python, it is a relatively simple process. Every developer has their own personal debugging method or tool they swear by. When it comes to Python, most developers use one (or more) of the following: print statements, traditional logging, a pdb debugger, or an IDE debugger.

Hans Ulrich Obrist once said that “everything I do is somehow connected to velocity”. We couldn’t agree more. As is in most companies, there’s always something affecting your team’s velocity, whether that’s a new work from home routine, a change in budget, or a variety of other reasons. So many influences are out of your control- how do you make sure that your devs are working at optimal velocity?