Ep 3 - Software Engineering for Systems Engineering

Software Engineering for Systems Engineering

Really, just wanted to warm my seat back into discussing the DevOps realm out loud. Going to dig deeper in each of these components as the series goes on. Could have titled the episode “Software Methodology for Systems Engineers” but where’s the click bait in that? :wink:

“Show Notes” lol

As a systems engineer we need to borrow and learn from software engineering:

 

Software methodologies

Version Control
SDLC
Testing
Tools and utilities
Algorithm Analysis

 

Chef is awesome :D

 

More on Algorithm Analysis later!
3 Likes

Relevant

image

4 Likes

for anyone that wants direct link:

https://traffic.libsyn.com/secure/forcedn/admindevlabs/Software_Engineering_for_Systems_Engineers_mixdown.mp3?dest-id=1403414

2 Likes

HAX0R

1 Like

I want to date this lady and she can absolutely buy me another beer.

3 Likes

You seem to be a no-bullshit, get things done kinda-guy, but I’ve dealt with a lot of bad devops in my life…

Complicating the !@#$ out of relatively simple things…

We blew 6 months on our project absorbing this byzantine process that turned out to be less than 1/2 baked but the head of the devops groups spun a yarn to management about process visibility and predictability that was backed by absolutely ZERO engineering actually using the “process” they had concocted… They only understand how their engineering went and had no concept for the rate of failure of experiments we MUST absorb to do real R&D.

We spent 75% of our time on process and had to pad our predications so wildly that we then got push-back from managment on why we could only commit accomplishing 10% of what we did the prior year. So, I gave them some gant-charts to show where the resources were going…

OMG… the only thing that saved us was being moved under a different division is taking a more cautious approach to that cluster!@#$…

My mantra to everyone regardless of power and position is “there is no ‘simply’ and ‘just’” Those words are Canries in coal mines. When they drop, you wil be dead soon.

Oversimplification is the devil and you have to balance planing and execution because no plan survives first contact with the enemy. People who fancy themselves architects who can design an entire system without some/a lot of experimentation are bad architects or the problem was simple enough that I’m not interested in it nor the right person to tackle it…

1 Like

Appreciate it! :smiley: And I can understand that.

I feel that way about Kubernetes and Jenkins. Not the tools themselves, as I think they’re alright and have their place. But the implementation of these tools for the most basic or simple task is insane. Something a cron job or a few shell scripts could do and we’re changing our entire ecosystem? C’mon, guise…

That sucks. Sounds like a nightmare. … Is this something you’d be willing to discuss on a future episode? :grin:

Man, those things are so cool, and you don’t need to buy fancy software lol. Well, that helps, but I’ve made some in Excel (gantt charts). Really great tool, as you said, to demonstrate where time is being allocated versus where it’s supposed to be.

Sounds like a quote for the motivational thread :grin:

damn, you’re pumping these out.

I thought this would be weekly.

2 Likes

Yeah :smiley:

I generally record them when I have time to sit down and do it or when I have an idea about a topic I want to do. They’re averaging weekly lol. Ten days between the first two and four days between this one. I’ll probably slow down as the topics become more advanced.

1 Like

This can be hard to do without risking running afoul of policies…

It’s relatively easy to write stuff down and delete the stuff that’s marginal… It’s harder to talk real-time about stuff and filter.

2 Likes