In this series of blogs "Developers Opinion", developers that actively work with integrations and FRENDS share their peer-to-peer opinions and experiences. This time, Paweł Kowalski from HiQ Gdynia shares his honest and casual observations on old vs. new ways of monitoring and Quality Assurance (QA) processes.
Imagine for a moment that you are a developer. It's easy. Just drink a lot of coffee and put some matrix wallpaper on.
So... now you are asked to constantly make sure that whatever functionality you have developed some time ago is working as designed (Quality Assurance aspect). Let's say it's one of the core functionalities of your platform, and without it your business will surely collapse.
Simplifying it a bit more: let's say it is a login functionality (in more complex cases it might be a happy path, data entry, etc.). It might be a closed environment, or internal network. Easy right?
Usually what happens is that functionality eventually breaks, and nobody notices it because server with a tool is down, support is late and you are likely to end up being chased at 3:00 am being asked why it's not working for a week.
As a result you have designed something that is understandable by both business and support. You did it in 5 minutes (actually I did, and it was 5 minutes literally). And it comes with the additional features to ease up you work:
And what comes to the documentation... Well, it has already been done automatically in a design phase.
And here comes the question: Why are not people doing it the second way?
The second way offers so much less ambiguity, it's self-documenting, saves so much on down-time of an application. Better customer experience.
Speaking for myself?
I've been myself there a long time ago, and I was building processes the first way myself. Belive me or not, you do not want to follow anymore the first option in today's modern world :).
Why the first way of doing things still prevails, you may wonder. Well, I think it's not that developers would not like to do it a smarter second way. Usually, what I have noticed, it's the business that does not provide the right set of tools. Maybe it's due to the lack of awareness or a learning curve (which is almost non-existent)? I don't know.
Please notice that this example was only a testing scenario. Imagine how many more processes related to your business you might do this way! For exmple, informing operations about a new lead opportunity, or synchronizing your business applications... Sky is the limit.
Option (1) involves people from support watching your monitoring-tool, they don't know the code or a process, you need to purchase additional machine to monitor the state of your app, and write documentation separately. And it still might break.
Option (2) involves DEV tooling where you outsource a part of monitoring responsibilities. It's pay as you go, or license-based, and it always works: One place. Multiple environments. Production and User Acceptance Testing (UAT). Unlimited processes. Multiple applications. Almost immediate service level agreement (SLA). Great support. Large community. Compliant with security and internal environments (closed/self-hosted).
And please note that those kind of tools actually do not take job from your developers. Such tools help them succeed, instead, but if you really don't have time, we have a team that can design and deploy processes for you ;).
Schedule a demo to get to know FRENDS and see how it can help you with projects.