I’ve noticed the term “tech debt” entering the OSS vernacular to represent stuff that is built now as a short-term workaround before the long-term solution comes online.
But what if it’s ALL tech-debt?
Everything we build needs to be supported for its natural life. The more we accumulate, the more that needs supporting. Support represents all the debt we leave behind, like going on a credit-card fuelled spending spree. And like any other debt, the more you collect, the more it compounds (due to the handshake analogy).
Agile and Microservices are great concepts for getting lots done in small increments without building a monolith. But there is the risk of creating a monolith of support unless we carefully plan subtraction projects to strip out nearly as much as we add.
I was recently involved in a micro project that added 1 new field to an existing report. Sounds simple. Unfortunately by the time all the rigorous deploy and transition processes were followed, to get the update into PROD, the support bill from our team alone ran into tens of thousands of dollars.
And that was without an incident / defect even being raised!
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
