As a technology leader in your organization, many of your decisions come down to allocating resources: balancing and prioritizing risk and reward, stability and velocity, the present and the future. In an ideal world, technical debt would always be addressed before it started accruing interest. Long-term maintenance and operations expenses would be accurately weighed against the short-term development expenses that could mitigate them.
Charity Majors, co-author of Database Reliability Engineering, shared a tweet that drives home how to approach the transition from single applications to a complex, distributed system of microservices.
@mipsytipsy. “Embrace the fact that everything is failing all the time - and it’s okay! We build for resiliency, not uptime.” Charity Majors, Twitter, https://twitter.com/mipsytipsy/status/1134499865335963648.
You can invest a lot in making any single system component reliable, performant, and scalable. The investment is often worthwhile and necessary, but what matters to users is the system’s uptime as a whole. Reliable components aren’t enough to make the entire system reliable if it’s unable to tolerate and recover from failures. Here are some thoughts about building your system for resiliency and two popular microservices patterns to cope with failure.
Many companies have long had some proportion of remote employees, but relatively few have taken the capability of managing remote employees to its logical conclusion of being entirely office-optional. In 2020, we’re all jumping into the remote-first experiment with both feet. There will be some awkwardness and issues, but this can and should be seen as a learning opportunity as well. Issues that once affected only a distant minority will now affect everyone, top to bottom. That temporary discomfort will be the impetus for rapid improvements in remote work that could otherwise have taken years.
As remote work becomes the new norm, leaders need to ensure the right structures and tools are in place for their teams to be successful. The DragonSpears team has been working remotely for years, so we put together various perspectives and insights to shed light on productive remote work and successful remote team relationships.
We’ve all seen charts of the software development lifecycle (SDLC). They often have a stage with a name such as “operate” or “maintain” that the development team will briefly mention in their enthusiasm to move on to the next stage: building new features. But the operational phase of the software development lifecycle is, in many ways, the most important; it’s where the rubber meets the road.
By making operability a priority for your software, you’re investing in a maintainable present and the data to build the future. Here are four steps effective software development teams take to ensure they get the operational phase right.
There’s an old saying among business leaders that also applies to software development teams: you need to work on your business, not in your business. The grind of daily work often leaves developers with little time to create more strategic and structural plans required to accomplish core business objectives. Without a focus on the foundation of your processes and practices, there is the risk of making all of that day-to-day work less effective than it could and should be.
Some dev teams have the flexibility to hire a specific person to focus on those structural, strategic issues. A small portion of them are able to stick to that division of labor, even in the face of immediate business needs, which is great. However, many teams benefit greatly from partnering with an outside software consultant to help them with the strategic analysis of the codebase, systems, and development practices. A consultant’s role is to help you find the best practices that make your processes and jobs more efficient and effective going forward.
Here are three ways a third-party code audit from an experienced software consultant can benefit your team in the long run.