process

meltdown-spectre The world is abuzz with stuff about the Intel bugs – so much so that Meltdown and Spectre are explained by xkcd better to the masses than most technical articles. It’s as if the world woke up and saw a small bit of what can happen within computing systems and, unfortunately for Intel, gets branded with Intel.

Did I mention Intel? Oh, don’t worry, it’s not the only brand that is getting sucked into this. Apple’s vulnerability to Meltdown and Spectre has also been admitted.

The potential is serious. But then, having seen code over the years that allowed pretty much the same thing– clearly, I fixed it where I saw it – I’m not as disturbed as the people presently flailing their arms until the next thing comes along. People will forget soon.

I’m not a chip designer, but the overall problem is pretty close to the Software Engineering issues the world presently faces.

People, generally – I still think of them as users – don’t care too much about technology. I’d say the same about management, too, in most companies – in the early 90s I said, “Management doesn’t know there is a fire until the flames are licking their asses.” This held true in just about every company I worked with until 2016, when I opted to start early on other endeavors to mitigate the risk of being an X-gen Software Engineer in a market that wanted millenial code monkeys.

Here’s the dilemma: Writing good code costs more time and money than most companies want to dedicate because, cyclically, they need to show profit faster because of increased competition in the sector.

Code monkeys are appreciated for fixing the bugs that they created in the first place, Software Engineers aren’t appreciated for the bugs that they keep from being introduced. And so, HR is always looking for code monkeys instead of true software engineers.

Venture capitalists and financiers care more about the commodity of Intellectual Property than the service of Intellectual property, mainly because people find it difficult to think of copyrighted or patented – or even company secrets – as a service. We live in an age where information and processes do not stand still; it’s not that there is Intellectual Property anymore that you can sit on – it’s that there is Intellectual Property that you have to build on.

But Intellectual Property as a commodity is how trading is done – like the statistics on a baseball card (for the Americans reading) of a living player that will be outdated the very next game. Copyrights, Patents, Trademarks, Trade Secrets – these are snapshots in time. They are not as fluid as what they represent. They are bureaucratic stop gaps to elicit profit, which has worked for a very long time because they were designed to. But what they were designed on is changing faster than this bureaucracy can accommodate.

So all of this leads to design flaws because the designs can’t possibly cover all permutations of how something can be used. It’s getting better, but by getting better it gives a false sense of security that makes the more elusive problems worse for our systems. As I wrote to someone querying about whether foreign processors would have the issue or other issues, I said, “Nothing is secure. Act like it.”

The world is changing more rapidly than the people changing it can keep up with.

Let that sink in.

And then, if you suffer some history, you’ll find it has always been this way. The future has a mind of it’s own.

The only way to mitigate things – the only true way – is for people to be more conscious of what they use. When I was growing up, because of how I grew up, I picked up the habit of understanding at least the basic functionality of everything I used. If it broke, back in the days before the Internet, in a ‘developing’ country, I had to fix it or throw it away.

Now, landfills are filled by slowed phones and antiquated technology. If I’m a dinosaur, I see the meteors and appreciate keeping things around a while when others are quick to buy the next new (untested) thing.

It’s a brave new world.

I’ll be in my garden.

Taran Rampersad — Courtesy Mark Lyndersay, LyndersayDigital

I hate having my picture taken. Over the years, I have found the best defense from cameras is to hold one. This has weakened in a day and age where every phone has a camera, and everyone wants to be seen with someone – but Mark Lyndersay needed a picture of me for TechNewsTT, where the majority of my writing has been published this year outside of my own websites.

In going to his studio, it was a rare glimpse for me into the world of professional photography. It was clear to me almost immediately, this amateur photographer, that it would take me at least a decade to do the editing I watched Mark do quickly, about how he managed his photos, and about why he did the things he did – a matter of simple experience that cannot be replaced with meetings and requirements discovery.

You see, I had been thinking of writing my own photo management software in Python – something to automate a lot of things. I had briefly considered this when I had begun selling some of my prints in Florida, and it was latent in my mind as a project to ‘get to’. In conversation with Sarita Rampersad, another professional photographer (unrelated), I had asked her what she used last year and why. It was clear that it would take more than a passing effort on my part to build something more useful than the tools she was using. The visit to Mark’s studio underlined this.

The Roots.

Reflecting on this on the way home, I went back to the very core of how I started working with technology. From an early age, I was encouraged – by rote and by whip, as it were – to observe what was being done to understand how it was being done. This was the root of the family business, the now gone Rampersad’s Electrical Engineering, a company that was built on fixing industrial electro-mechanical equipment with clients ranging from the U.S. Navy to someone who just needed their water pump repaired (Even WASA).

This background served me well over the years, and understandably frustrated managers and CEOs. Knowing the context of how things were used allowed for for useful processes and code; it allowed for things to become more efficient and allowed things to be written to last instead of a constant evolution of, “Wouldn’t it be nice if?”. In a world of agile processes, the closest thing to this is the DevOps iteration of Agile which even people who practice Agile haven’t heard of (because they are soundly in the Agile Cave).

DevOps is a form of Agile where every stakeholder is directly involved. And that, to me, is also a problem because of the implicit hierarchies and office (if only office) politics is involved. It’s a bleeding mess of tissue to sew together to form a frankensystem, but at least that frankensystem is closer to what people actually need. Assuming, of course, they understand what they need.

To me, it boils down to studying what other people do.

Observe, Analyze, Communicate, Build.

When I started as an ‘apprentice’ programmer, this was drilled into me by an Uncle who was a Systems Analyst, and ‘allowed’ me to write the code for projects that he was working on. He didn’t boil it down to observe, analyze, communicate and build; I refined that myself over the course of the years.

No matter the process, it all boils down to someone able to bridge how people work/play to get something done to understand what is needed, and how to make their lives easier through automation and information structure. Observing people do their jobs is important, analyzing it secondary, but the most important part is the one thing that an AI cannot yet do: Communicate, the process of listening, speaking (or writing, or…), and then feedback. This process is most important. In priority of importance, software engineering and I believe any form of process or structural engineering is:

Communication
Observation
Analysis
Build

This is not the order in which things are done, of course, but the emphasis that is most important in understanding how present systems work and how future systems should work.

So often over the years, I’ve seen software engineers relegated to the role of code monkeys with emphasis only on ‘Build’, when the most important parts are about ‘building what is needed’. This is where business analysts got introduced somewhere along the way, but they too are put into silos. This is underlined by HR departments focusing only on the ability to ‘build’, where analysts are expected to be a different sort of role. When these roles were split, I cannot say, but to be both is something that is too large and round to fit in small square holes of the modern enterprise.

It is lost, eroded, and there is a part of me that wonders if this is a good thing. Studying what other people do has allowed me to do so many things within and without technology, and it worries me that in a future where AI will be taking over the ‘Build’ that software engineers aren’t being required to focus more on the soft skills that they will need in the coming years.

Sure, the AI can build it – but is ‘it’ what needs to be built?

KnowProSE.com

Where one line can make a difference.

Beyond Naughty Processors.

The Study Of What Others Do.