Tag: sdlc

5 Common Distractions that Risk Breaking up Your Product Focus

Posted on by eugene evdokimov

Maintaining product focus is the best way to guarantee a successful business. As the late great Steve Jobs put it:

 “if you keep an eye on the profits, you’re going to skimp on the product… but if you focus on making really great products, the profits will follow.”

There are a wide variety of statistics available on how much time developers actually spend writing code, anywhere from 25% to 32%. Whichever is true, these studies show that your developers could (and should) be spending more time focusing on actually developing your product. In this post, we’re going to examine some of the common roadblocks developers face, and how you can enable them to overcome them and optimize your IT costs.

Distraction #1 – Sifting Through the Noise

A complex system or product can produce millions of logs a day. Some of them hold important information that may need to be addressed, but for the most part they simply cause a ton of noise. Noise is killer for productivity.  In order to keep things running smoothly, with minimal maintenance from developers, you’ll need a solution that can provide succinct error analysis. 

One way to do this is by clustering common logs based on shared attributes. Automated clustering of similar logs is the first step to giving your developers more time in their day to focus on product development. Coralogix uses new Streama technology to automatically analyze your logs and prioritize the ones that hold the most value for your business.

Distraction #2 – Trying to Understand What’s ‘Normal’

Understanding what constitutes ‘normal’ behavior in complicated systems is tricky. When dealing with multiple releases per day and the multiple factors involved, it gets even more complicated. 

One common way developers are alerted to the effects of system changes is by relying on threshold alerts. Threshold alerts rely on manually set parameters which are time consuming and commonly lead to false positives (i.e. more noise). Replacing these alerts with a machine learning solution that can understand your system and product’s baselines and adjust dynamically, will keep your team on task and only alert them when they’re needed. No more wild goose chases.

Distraction #3 – Staying on Top of Technical Debt

Nobody wants to worry about technical debt, that’s why it exists, but it’s important to recognize that it only becomes more troublesome as time passes. Every known error that’s released to production can mean a week of troubleshooting waiting for your developers. That’s a lot of time being pulled away from product development.

Plus, it’s expensive! If you want to try and quantify the actual cost of remediating technical debt from known errors, it’s between $3.61 and $5.42 per line of code. That cost comes from the time taken to apply fixes to issues caused by known errors in production.

Distraction #4 – Upgrading Supporting Systems

Monitoring and logging systems are incredibly important for any organization. Upgrading, managing and optimizing these systems is equally as important, but is also a huge distraction from your product. 

When your engineers upgrade your ELK stack, they aren’t focused on product development. Your ELK stack forms a powerful part of your technology, but it isn’t your product. Your development team won’t have a product-focused mindset when they are applying a fix to each index following the latest Elasticsearch upgrade. Switching to a managed log and monitoring solution will help. Focus on your product and leave log management to the specialists.

Distraction #5 – Responding to Releases

Once you release a feature, a development team with a product focus ought to be working on the next release. However, releases sometimes have unpredictable or unforeseen impacts on your overall build quality and system performance. 

The ability to carry out post-release reports on overall system performance is key for maintaining product focus. This allows your developers to move onto the next big thing.

Product Focus and Centricity with Coralogix

What’s the bottom line? A strong and independent logging and monitoring system underpins a development team’s ability to do what they do best. Coralogix provides expertise-driven out-of-the-box functional and scalable logging solutions, reducing time spent on activities which detract from product focus.

Loggregation gives your developers a succinct overview of all your log outputs, clustering them based on commonalities and saving them time when troubleshooting. Combine this with an advanced, unified UI and an intelligent open search functionality, and the time your developers spend on tasks not related to product development will reduce dramatically.

Coralogix deals with billions of logs per day for customers big and small through by offering a fully managed service. Using intelligent machine learning, Coralogix can establish performance baselines and identify known error patterns automatically. This scalable solution gives tangible relief on development resources, allowing producthttps://coralogixstg.wpengine.com/docs/user-guides/monitoring-and-insights/anomaly-detection/new-error-and-critical-logs-anomaly/ development to take priority.

Automated benchmark reports give your team total awareness of the impact that new releases will have on build quality. This Coralogix feature means that you’ll always be up to date on your system’s health.

These offering and Coralogix’s overall innovative spirit ensure that your developers will have more product focus.

Force Multiply Your Observability Stack with a Platform Thinking Strategy

Posted on by eugene evdokimov

Platform thinking is a term that has spread throughout the business and technology ecosystem. But what is platform thinking, and how can a platform strategy force multiply the observability capabilities of your team?

Platform thinking is an evolution from the traditional pipeline model. In this model, we have the provider/producer at one end and the consumer at the other, with value traveling in one direction. Platform thinking turns this on its head, allowing groups to derive value from each other regardless of whether they are the users or creators of the product.

In this article, we will unpack what platform thinking is, how it fits into the world of software engineering, and the ways in which using platform thinking can revolutionize the value of any observability stack.

Platform Thinking – A Simple Explanation

Traditionally, value is sent from the producer to the consumer and takes the form of the utility or benefit gained upon engagement with whatever the product/service happens to be in each case. Financial value obviously then travels back up the pipeline to the owner of said product/service, but this isn’t the kind of value we’re concerned with here.

It should go without saying that any successful change to a business model (be it technological or organizational) should lead to an increase in financial value. Otherwise, what would be the point in implementing it?

Platform thinking is certainly no exception to the end goal being profit, but the value we’re discussing here is a little more intangible. When we say ‘value’ we are referring to the means by which financial ends are achieved, rather than the ends themselves.

So How Does Platform Thinking Apply to Engineering?

The above explanation obviously makes a lot of sense if your curiosity about platform thinking stems from financial or business concerns. However, that’s probably not why you’re reading this. You want to know how platform thinking can be applied to your technical operations. 

It’s great that platform thinking could generate more revenue for your company or employer, but in your mind this is more of a convenient by-product of your main aim. You’ll be pleased to hear that the benefits of implementing a platform thinking approach to your operational processes will be felt by your engineers and analysts before they’re noticed by the company accountant. 

As we covered in the previous section, the value added by platform thinking comes in the enabling of collaboration and free movement of value between groups on the platform. Financial value then comes from the inevitable increase in productivity and quality of delivery that results.

Platform Thinking in a Technical Context

A technical ecosystem founded on platform thinking principles means that everybody involved, be they an individual engineer or an entire development team, has access to a shared stack that has been built upon by everybody else. 

Engineers work and build on a foundation of shared tooling which is continuously being honed and refined by their peers and colleagues. Anybody joining enters with access to a pre-built toolbox containing tools already tailored to suit the unique needs of the project. 

The productivity implications of this should go without saying, but they’re astronomical. Any engineer will be able to tell you that they spend a disproportionately large amount of their time on configuring and implementing tooling. Platform thinking can significantly reduce, or even remove entirely, the time spent on these activities.  

Observability- Why It’s Useful

Observability and monitoring are essential components of any technical ecosystem. Be it project-based development or BAU operations and system administration, a healthy observability stack is often the only thing between successful delivery and system wide outage. 

A well-executed observability solution prevents bottlenecks, preempts errors and bugs, and provides you with the visibility needed to ensure everything works as it should. Without observability being a high priority, troubleshooting and endless investigations of the logs to find the origin of errors will define your development lifecycle.

In our highly competitive technology market, the speed and efficiency observability enables can often be the difference between success and failure. Understandably your observability stack is something you’ll want to get right.

Freeing Yourself From Unicorns 

Here’s the thing – not everybody is an observability mastermind. The front-end JavaScript developer you hired to work on the UI of your app isn’t going to have the same level of observability knowledge as your back-end engineers or systems architects. It’s going to take them longer to implement observability tooling, as it’s not their natural forte. 

Rather than attempting to replace your front-end UI dev with a unicorn who understands both aesthetic design and systems functionality, you could instead implement a platform thinking strategy for your observability stack. 

Shared Strength & Relieved Pressure

In any project or team, the most skilled or experienced members often struggle to avoid becoming the primary resource upon which success rests. Engineers enjoy a challenge, and it’s not uncommon to find that the ambitious ones take more and more under their belt if it means a chance to get some more time with a new tool, language, or system.

This is a great quality, and one that should be applauded. However, it also means that when your superstar engineer is out for vacation or leaves for new horizons, the hole they leave behind can be catastrophic. This is especially true when the skills and knowledge they take with them are intrinsically linked to the functionality of your systems and processes.

By implementing a platform thinking approach your investment in your observability stack transforms it into a platform of functionality and centralized knowledge which all engineers involved can tap into. Not only does this reduce pressure on your strongest team members, it also means if they leave you don’t have to find a fabled unicorn to replace them.

A Platform Observability Approach

A platform thinking approach to the observability of your ecosystem enables every developer, engineer, analyst, and architect to contribute to and benefit from your observability stack.

Every participant will have access to pre-implemented tooling which is ready to integrate with their contributions. What’s more, when new technology is introduced, their deployment and configurations will be accessible so that others can implement the same without a substantial time investment.

This in turn significantly increases the productivity of everyone in your ecosystem. The front-end UI developers will be free to focus on front-end UI development. Your systems engineers and analysts can focus on new and creative ways to optimize instead of fixing errors caused by ineffective tracing or logging.

In short, a collectively owned observability platform enables everyone to focus on what they’re best at.

Force Multiplied Observability

The aggregate time saved and pooling of both resources and expertise will have benefits felt by everyone involved. From a system-wide perspective, it will also close up those blind spots caused by poor or inconsistent implementation of observability tools and solutions.  

You can loosely measure the efficacy of your observability stack by how often outages, bottlenecks, or major errors occur. If your observability stack is producing the intended results, then these will be few and far between. 

With a platform thinking strategy the efficacy of your observability stack is multiplied as many times as there are active participants. Every single contributor is also a beneficiary, and each one increases the range and strength of your stack’s system-wide visibility and effectiveness. Each new participant brings new improvements.

By creating your observability process with a platform thinking led approach you’ll find yourself in possession of a highly efficacious observability stack. Everybody in your ecosystem will benefit from access to the tools it contains, and productivity of your technical teams will leap to levels it has never seen before.