The Study Of What Others Do.

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:

  1. Communication
  2. Observation
  3. Analysis
  4. 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?

Evolution: Process Trumps All

3D view of Mar03wjc1bOnce upon a time, software was sold on disks that were actually floppy. They were encased in boxes, with user manuals.

Then the disks were no longer floppy, but they were called floppy as a sacrifice to the Gods of Inaccuracy.

Then the Internet came along, and you could buy the boxes over the Internet.

Then you could download the applications over the internet when you purchased them.

And finally, Software as a Service (SaaS) came into being, and all was basically the same only faster (and with significantly worse documentation).
And the people were generally as miserable as they were, and could be disappointed at a faster rate when they found bugs, or when systems went down, or when their internet access was sloppy.

The real difference between competing companies now is how they produce and maintain the software. That’s the process.

Bugs happen. How fast can the bug be fixed, without introducing new ones? That’s the competition. That’s where competing companies actually should be competing, because the faster a company can fix bugs, the faster it can implement things as well.

That boils down to Software Process. And that’s why Agile, Lean, DevOps and so on are so important.

Because nobody is ordering boxes from the back of magazines anymore and getting it in the mail a few weeks later. They want it now.

If you don’t even have a software development plan (SDP) for a project, you’re already behind.

 

 

 

The Confusion On DevOps

devops in a boxI was in an interview with a candidate for a Software Engineer some time ago. We had the usual suspects at the table and me, the unusual one at the interview.

I’d read the guy’s resume. He claimed some game programming, and he also claimed to have experience with the full SDLC with both the Waterfall and DevOps methodologies. One of our people, notorious for academic questions, was pulling some of his punches related to .Net. He trotted out his usual questions on design patterns (he sure did love his MVC – let’s call him Mr. MVC), and he continued with his notorious monopolization of the interview. When it finally got to my turn, I asked a XOR question – the candidate had never used it.

So then I asked him about the strengths and weaknesses of Waterfall – and on DevOps. Mr. MVC quipped that he didn’t think we were hiring for the DevOps department, and I ignored him since I did not want to straighten out his ignorance in front of a candidate (though he had no problem being a jerk when he was wrong). The candidate answered the questions well enough, and I let it be.

But looking back, I couldn’t help but think that Mr. MVC was confused by DevOps because:

(1) We had a department by that name.

(2) He didn’t actually know about what DevOps was,

(3) He hadn’t read the resume and noted ‘using Waterfall and DevOps methodologies’.

It surprised me that Mr. MVC didn’t know about it, and it surprised me more that he’s now basically in charge of the Agile process at that company but wasn’t familiar with DevOps itself – particularly when the end goal is continuous integration. That’s sort of what DevOps is:

…Agile software development paved the way, steering away from the waterfall method of software development toward a continuous development cycle. But it didn’t include the operations side so while development could be continuous, deployment was still waterfall-oriented.

In a DevOps environment, cross functionality, shared responsibilities and trust are promoted. DevOps essentially extends the continuous development goals of the Agile movement to continuous integration and release. In order to accommodate continuous releases, DevOps encourages automation of the change, configuration and release processes…

So, by having DevOps on his resume, the candidate had opened himself up to all manner of questions on Agile, as well as continuous integration – things which, months later, would be brought up by the CTO.

And no one – not one soul – called it DevOps. Why? Likely because they got rid of the department that they used to call DevOps. This was largely because they sabotaged it by not giving it the appropriate tools for continuous integration, and the fact that the lack of documentation made the relatively fresh department more likely to fail with manual deployments.

I write all of this because I encountered it at one of my own interviews with a company. We were talking about continuous integration and the mismatch between Agile and Continuous Integration when it comes to involving Operations – they are typically not involved with Scrums and are therefore less likely to be prepared. That’s where DevOps comes in.

DevOps has been around a while. Waterfall went to V-model that went to Agile – and now DevOps is king. Or should be.

But it’s surprising how many people don’t know about it.

Suggested Reading: