Surviving the Engineering & Programming work in a Regulated Environment

Surviving the Engineering & Programming work in a Regulated Environment

Knight vector created by macrovector -

This is probably.. the darker side of the story of being a programmer in a low-risk appetite environment. Doing Software Engineering or Application Development is a risky operation because of the rate of project failure, the return doesn't meet the investment poured into the project. Just how much ROI do you think in the average scenario? Think about High turnovers of Developers because the opposite pastures are greeners and the conundrum of Software Development in a complex landscape...

The Ideal Development Environment

I think we may have heard awesome Continuous Integration, Continuous Deployment (CI/CD), powerful collaboration tools such as GitHub discussion, then Slack or maybe Discord. Perhaps a picture like this of a small conversation sparked in the morning, a few persons throwing some ideas in the chat, then some Pull Requests and a few more code improvements on top of each other, supported by peers from various timezone, then voila .. an amazing product is born in the evening. Something akin to GitHub Universe 2020 Opening Keynote here:

To me, that's an ideal workplace and amazing Developer Experience. Also, that can be.. way too ideal kind of perception towards the software industry. I mean in real life we don't get to film all the awesome chain of events right? The software world is often filled with stress and dismay due to misunderstanding, poor communication, and reluctance to collaborate... likely of an unfavourable interaction in the past, and communicating with another person maybe it's a total paradox in our work: communicate with the machine.

The reality that I'm experiencing

The reality that I'm living in, full of people from other fields, other expertises, probably you're the just the rare one speaking of IT programming languages around them. Just when you happen to find another programmer peer, that I realize; most of us work in a silo. We try to avoid code conflict, hopefully picking up a task that solo focus on individual contribution, enjoying the zen of programming, submitting and everything went well. Why do we become the lone developer? Maybe mainly we're serving and pairing with another non-IT colleague most of the time, attempting to deliver something for them. You might have seen the comical scenario of 9 persons watching and managing a single Developer to deliver the piece of much-anticipated work. This has a solid reference to the real world of software development.

At times, I have doubts about why do we even want to do custom programming? Perhaps just getting something off the shelves save us a lot of time, in bug-fighting, an endless cycle of imperfection and iteration, and never-ending piles of technical debt... overwhelming us.

Each kind of organisation has their own dilemma with Information Technology and their share of problems. Just like someplace people are struggling for food and basic necessity. Here are the two extreme opposites that I met, at least around my circle. There are smaller organizations, with wild dreams, and a lot more freedom to explore, unregulated where innovation is high, yet.. often change direction, easily switch commitment, most of the projects developed half way, and potentially keep inside the fridge. Yet some projects started for a while but without a real customer, segment to sell to.

Information technology investments are costly. Discount the hardware, laptop that's used for coding, the electricity bills, and then compensation for the programmer, some software costs money, and some elegant software also costs support fees, and then some hosting solutions on the cloud costs operating fees, compute power charges, data transfer charges, and API rate charges, ...

What's more software and technology are quick to obsolete. it's the game of never-ending version upgrades, chasing for security patches, releases, and matching up with the greater ecosystem of technology dependencies.

On Making our code and our work auditable is truly a challenge

we're the dangerous breed of people, akin to builders who build houses but with a lot of invisible bricks, and intangible underlying pipes and wirings. Pity the folks who want to buy the house from us. but may not even have the chance to claim the warranty nor to discuss the intangible problem with us... because a lot of problem is there, but it's much covered in a black box, not that easily accessible to others like those word documents that could be inspected upon... it demands just programming literacy.. then we're 'forced' into writing a lot more documentation more than codes we wrote, "sometimes".

in a regulated industry, basically, every customer wants some form of safety. They are worried about the software breach or malicious code inside.. thus various government departments are set up to do inspections at their best effort to inquiry, to 'interrogate', to carry a zero-trust policy against every single piece of code that's written and intend to go to the mass. the world is right about it, which also.. we're at the disadvantage ends if we don't get enough support to help justify our work is clean.

Development can become a hassle when we're diverted from just writing code, now we need to justify our code.

Survival and finding the muse amidst the constraints

and so there is hope. software .. some time ago was much less accessible to many of us. Luckily. nowadays we have the luxury to work with more open sources libraries and enjoy more free tiers, trials, and evaluation (long term) copy, all these minor efforts do help to bring the development circle a lot breathable. Hence make use of these available tools. Try to reduce the number of codes, towards less code, or low code, or maybe zero-code.

Enterprise solutions can be really fun if we get to see them through the opposite lens. We may have been sold to the Cloud technology, yet there is more to meet the eyes of those offering on-premises solutions, local data centres, and various solutions to help manage the ownership of data, infra, and while meeting all kinds of compliance requirements.

I learnt all these enterprise architecture just by accumulating experience and exploring the uncharted territory in attempting to build something new to the landscape, deliberate it in the Enterprise Architecture forum, people may push back on your novel idea, ask you to re-evaluate existing available solutions, yet might also be in goodwill to offer what's closest to the availability that they could provide to you.

There are some gems from what the previous generation has set up and invested in. For example, those offerings from Oracle, Dell, Nutanix infrastructure, and Zerto technology .. everything that powers up the infrastructure and the overall solutions, they worth something, and they are worth discovering the philosophy behind those products. Although these are enterprise options that are less accessible to us as an individual. it might have saved the organization for many countless audit events, compliancy checks, ISO standards, and keeping a steady income, such that.. we could sit tight and get the monthly wages predictably.

Assembling the delightful component to shape the Dev Experience for Next Generation

I'll call it finding the muse in the sea of conundrums. Which that combination would unlock your innovation, break your limits, and sugarcoats the pain one's having in the work environment. So there is a lot we could do, we could try to embrace GitHub and CI/CD tools where applicable. formulating the 'grey area' for software development culture first. then produce fully compliant delivery insert onto the regulated enterprise component, submitting source code to the centralized VCS, such that it runs on the on-premises continuous integration, deployment pipeline tools, despite we don't have the best in class infrastructure, at least most of the time, the server are reliable, monitored by Security department, and knowing that a number of the department from the shared services would aid us whenever we lodge a service request... that's the benefit of enterprise programming. all it takes is to be brave to network outside your computer, work beyond what's the 'screen' in front of you, work with people, focus on solutions over problems and let that (your screen, your computer, your keyboards, your mouse) be the windows that bring you to communicate with the world out there.

Go Forth, and find your ally!

Did you find this article valuable?

Support William Cheong Weelau by becoming a sponsor. Any amount is appreciated!