Forum Time

[Orestes Munn]

I agree with Rich and Beau and would add wireless networks to the list of things to be very careful about. However, my personal data, including my security investigation, have been stolen at least five times that I know of and probably many times more. We are at much greater risk from the sloppiness of our government and commercial overlords than our own.

[Jamie]

The computer I use to update my ECU is never allowed to connect to the internet to avoid malware and the second most frightening scourge - automatic updates.

[Ajax]

I agree with Rich and Beau and would add wireless networks to the list of things to be very careful about. However, my personal data, including my security investigation, have been stolen at least five times that I know of and probably many times more. We are at much greater risk from the sloppiness of our government and commercial overlords than our own.

That is a correct and depressing statement.

[BeauV]

I agree with Rich and Beau and would add wireless networks to the list of things to be very careful about. However, my personal data, including my security investigation, have been stolen at least five times that I know of and probably many times more. We are at much greater risk from the sloppiness of our government and commercial overlords than our own.

I couldn't agree with Eric more on where the Real Risk is on the network. One need only read about the massive break-ins that are announced ever few months in the press. Then, consider that many companies (Uber and Yahoo - I'm looking at you!) bury massive break-ins to avoid the embarrassment. This means that there are many many more than folks admit to.

For these reasons and more, I'd +100 Eric's comment about adding the network. That said, we've all known this for well over two decades. By its nature there is a fundamental conflict between the desire of the Internet to route around failures to communicate, if one can ascribe intention to a network of computers, and our desire to have high levels of security about our information. Consider that securing our information is viewed by many of the features of Internet architecture as a "failure to communicate". (Which should be said in the drawl of the Warden in Cool Hand Luke, a must-watch movie.) The very architecture which makes the Internet so robust and reliable, is working against securing it from access. Knowing this, we need to either take things off of the Internet, the way Jessie removes his car-programming computer and I remove my banking activity) or we need to find a way to be insured against loss.

Consider that credit card fraud is a massive area of loss. Yet, we don't make it more difficult to use credit cards because we as a country have decided that simply paying higher fees to insure against loss is worth more to us than using higher levels of security/inconvenience. This approach is starting to take shape on the Internet. Sadly, or perhaps gladly, there aren't any big Banks serving as intermediaries on the Internet and underwriting the losses. Despite aggressive attempts by the Telco Carriers to insert themselves as intermediaries (see Net Neutrality).

In the mean time, whenever possible simply don't use the Internet for things that can cost you a bundle if you're hacked.

[Orestes Munn]

I will also admit to being phished successfully, but, as far as I know, only by our own very good and drastically underpaid IT security folks.

[kdh]

How much time do we spend entering passwords and taking off our fucking shoes to get on an airplane? These are not significant risks we're abating.

[Olaf Hart]

As we are over 60 they let us keep our shoes on ....

[Ish]

As we are over 60 they let us keep our shoes on ....

Our security makes me keep my shoes on.

[kimbottles]

We had one guard say “you do not need to take your shoes off” (we are 70 & 69), the next guard yelled at us for not taking our shoes off......

[Orestes Munn]

We had one guard say “you do not need to take your shoes off” (we are 70 & 69), the next guard yelled at us for not taking our shoes off......

TSA Precheck obviates all that for domestic travel.

[kimbottles]

We had one guard say “you do not need to take your shoes off” (we are 70 & 69), the next guard yelled at us for not taking our shoes off......

TSA Precheck obviates all that for domestic travel.

We are Global Entry and our boarding passes WERE PreCheck!

It was weird, but we just took our shoes off and proceeded on.......

I don’t fight unwinnable fights anymore.

[BeauV]

We had one guard say “you do not need to take your shoes off” (we are 70 & 69), the next guard yelled at us for not taking our shoes off......

TSA Precheck obviates all that for domestic travel.

We are Global Entry and our boarding passes WERE PreCheck!

It was weird, but we just took our shoes off and proceeded on.......

I don’t fight unwinnable fights anymore.

I'm reminded of what my son said to me once: "When someone is arguing with an idiot, there are two idiots arguing."

[Olaf Hart]

So here is a question, who understands this?

https://builttoadapt.io/what-happens-wh ... 318a3c9894

[Orestes Munn]

So here is a question, who understands this?

https://builttoadapt.io/what-happens-wh ... 318a3c9894

Not I, but I'm sure it's wicked important.

[Olaf Hart]

I was hoping I could send him some insightful questions and elevate his perception of his fathers IT skills...

[kimbottles]

I sent the video to my IT son who will certainly understand it, so stand by, we might get some good material to use Paul.

[BeauV]

Sadly, I think I do. What’s the question?

(We in tech certainly clutter up simple thing with heaps a mumbo-jumbo!)

[Olaf Hart]

I don’t even know enough to know what to ask Beau.

There is a certain irony a doctor being caught out by his sons jargon, I thought we were masters of the genre...

[Orestes Munn]

I don’t even know enough to know what to ask Beau.

There is a certain irony a doctor being caught out by his sons jargon, I thought we were masters of the genre...

It seems to me that virtually every medical term (outside of the psychiatric lexicon) Greeky or Latinoid, no matter how stilted or obfuscatory, has an agreed and readily explainable physical referent. I am not sure this holds for all brands of jargon.

[Jamie]

So here is a question, who understands this?

https://builttoadapt.io/what-happens-wh ... 318a3c9894

I think he's trying the explain the scrum development process and how to deploy it. I won't say I understand agile process - I'm going through the process of trying to understand.

My mental short-cut to understand scrum is that it's a process that kind of makes software development similar to batch mfg custom products.

The business defines it's next set of business objectives that get prioritized, product owners (who act like product managers in the mfg world) from the Tech Dept are responsible for understanding those objectives in term of the end-users needs and then translate that for the developers to go code. Once the amount of Tech resources is determined, it's organized into sprints where developers work of a discrete set of application development to be delivered over a discrete period of time, in my case a period of a couple weeks. Big development tasks may take 2-3 or more sprints. Small ones might take one sprint or less. At then end of each sprint the developed software is delivered to the users and reviewed. Once a week we review the sprint to see if we are on-track to delivery what was promised. Once a month time allocations for the product owners and developers are reviewed to see if we stayed on-track at a higher level and the product backlog is updated and once a quarter the business priorities are reviewed in a more systematic way and the product backlog is also updated accordingly. The hard thing about this process is that is requires people to change how they think about their roles and it requires a certain amount of mfg like discipline.

What I've learned so far is that Tech and Tech Development is a very different animal than IT. In fact we have a Tech dept and are now putting in place an IT department now that we've grown enough to need people dedicated to supporting users as opposed to development. Developers don't seem to make good IT the way we non-techies think about it.

Tech seems a like like Finance. Lots of common sense ideas hidden behind mumbo-jumbo. T-shirt sizes, tech stacks, Scrum Master, opening up APIs...etc...and there are a lot of specific software tools with funny sounding names.

There is no Plumb's Guide for IT, unfortunately.

[Olaf Hart]

Thanks, I understand a scrum.

Spent a lot of time in them in my youth.

Sounds more like a ruck to me.....

[Jamie]

Thanks, I understand a scrum.

Spent a lot of time in them in my youth.

Sounds more like a ruck to me.....

I had to look up "ruck".

[Olaf Hart]

Interesting word, it’s both a noun and a verb.

Couldn’t see it catching on as business lexicon in the current environment ....

[Jamie]

Interesting word, it’s both a noun and a verb.

Couldn’t see it catching on as business lexicon in the current environment ....

I've not seen it as a verb. I believe you're right. Probably unusable outside of the anglosphere because of the rhyme.

[Rob McAlpine]

Thanks, I understand a scrum.

Spent a lot of time in them in my youth.

Sounds more like a ruck to me.....

Dissimilar to a maul...

[Olaf Hart]

A maul is when you are standing up ...

[Rob McAlpine]

A maul is when you are standing up ...

Been in plenty of both. More specifically, in a ruck the ball is generally on or near the ground, in a maul it is off the ground, or so I recall.

[Ish]

A maul is what we use when an axe won't split the log. I have two of them, for some reason.

[BeauV]

Reverting to IT, Jamie has it right.

Here's some background:

In the bad old days of 30 years ago, we wrote large pieces of software - called monolithic software. It took a genius to get it done and was quite fragile, meaning that when changes were required (and they always are regardless of how well specified or designed the software was) the darn stuff broke. The old IBM Mainframe OS for the System 360 was a prime example. It got to the point where they just documented the bugs, as every time they tried to fix them they introduced more bugs than they fixed. Regression testing after a change was crazy and didn't work well.

So, the concept of replaceable parts was introduced, much like it was into weapons at the time of the US Civil War. Since then, there have been any number of fad-like attempts to describe the process of building software out of parts. A giant advantage of the Unix Operating system, which has now emerged as both MacOS and Linux, is that work is divided up into components and linked together with something called a "pipe". This is a standard way for software bits to talk to each other. Similarly, Application Program Interfaces (APIs) emerged as a way of defining interfaces, and more recently functional programming has emerged. A "Functional" approach is to simply call a function in your software and the sub-strait takes care of starting the required software, running it, and returning a value. Oddly, this is often called "Serverless" just to confuse folks.

At the root of all of this is a decomposition of the elements of software so that it can be re-used rather than re-written. Simon Wardley, who consults for all sorts of big government and private organizations has estimated that over 85% of software is redundant and only exists because the author didn't know the problem was already solves or for some political reason within the organization. He's fun to read. I think the redundant level is more like 95%, which is absurd but Engineers want to engineer and don't really want to research what some other Engineer did two years ago.

Once you've decomposed your problem into little bits two good things happen: First, you can actually comprehend the problem being solved and nail it cleanly. Secondly, you can then publish that capability as a service. (Serverless is a sub-set of this general trend limited to functions.) Generally, this then allows folks to have short sprints, as Jamie has described, were they get a specific chunk of work done on the way to building a component. Making these components available as a service first emerged ages ago as Service Oriented Architecture (SOA), and has continued to progress into smaller and smaller bits called Microservices. Of course, this has simply shifted the problem. Now there are Service Brokers and Service Meshes and on and on and on. But generally things are getting better.

In my lifetime software has improved massively and older approaches have been left behind and ultimately crushed by competitive forces as re-use has become better and software architectures have become more structured. Today software engineers would think it absurd if someone suggested a monolithic operating system like Windows or OS-360.

One final point, Jamie is dead right: Systems Software Engineers are not IT folks. The engineers are fascinated by doing the engineering, which is a lot like naval architecture or any other form of complex engineering. IT folks are motivated by solving a business problem including keeping that solution running and changing it to keep up with the changing requirements of the business. While there is a class of software engineering called Applications Software Engineering, and it is tasked with building custom application which the IT folks need, these folks are mentally more like IT folks that software engineering folks. The two folks have very different expertise. Recently, folks have tried to get the Application Software Engineers to also do the operational side of IT, actually running the software, this is called DevOps. While it's helpful to the IT organization, it's rather pointless for the System Software sorts. The difference is a bit like the gap between a Naval Architecture and Shipbuilding company and the Crew that goes to sea on the resulting ship. The first designs and builds the ship, the second sails it and fixes things that go wrong along the way. The analogy isn't quite a perfect fit, but it represents the differences in goals and attitudes.

[kdh]

I'd never heard that perspective on Unix, Beau. Of course a "pipe" is just a standard for communication.

We do our work using a software package called "R" (an open recent flavor of "S," developed at Bell Labs, as was Unix) on Linux. It's modular. Overriding principles like pass-by-value vs by-reference have been abandoned, which has improved its flexibility.

Importantly, contributors provide "packages," a set of functions with documentation, which keeps things organized. Further, the language is object-oriented, with mostly simple inheritance schemes. It's widely used; what's good gets incorporated and what's not is abandoned.