Plaid spanked by 2018 Escalade

[Yadkin]

Originally Posted by dvarapala

Wrong-o.

We can add the DO-178C software development process to the long list of things you are ignorant about.

Technical terms special to your non-profession. Big wup.

[sublime1996525]

Originally Posted by Yadkin

I'm always amused by education snobs.

As someone who went to a community college, I'm definitely not an education snob

[Yadkin]

Originally Posted by dvarapala

Almost as amusing as licensing snobs.

"Show me on this doll where that bad Yadkin man hurt you."

[Yadkin]

Originally Posted by Steve_R

How were airplanes built before computers and software existed? How about bridges? Nuclear reactors and weapons? Etc. Etc. Etc.

Inquiring minds...

Modeling and hand calculations. Full-scale mock-ups. Checks and testing to failure.

[Yadkin]

Originally Posted by Egnalf

talking about people or things "spanking" each other on the internet speaks of low character.

How ironic.

[Yadkin]

Originally Posted by GrandSportC3

It's shocking how little people seem to know about the software life cycle.

1) The product person (or engineer) requests a certain feature
2) The Business Analyst and Development leads meet with the product person to work on requirements for the software to be built. They create a business requirement document.
3) Development lead and business analyst meet and determine what programs or routines have to be created. This is to be discussed with the development team. The work is broken down and each component is assigned to developers. If this is a larger undertaking, each developer has to create a technical design which is then reviewed with BA and the tech team. Once all agree that the tech design is good, each developer will work on their piece and unit tests their piece.
4) once code and unit test is peer reviewed, it is moved to the QA team (Quality Assurance). All the programs for thr project are tested together. A SIT (System Integration Test) is performed and all potential scenarios are run through the system. If all the test cases are closed and successful, the software will then implemented in production or in case of car software, sent via update to the cars.

I've been a Software Engineer for like 35 years. I work for a huge financial institution and I know very little about banking, yet, I write programs for the bank. I don't need to have banking knowledge. That's what we have the BA's for.

It's shocking about how little people know about the basic infrastructure that allows civilization to exist: water supply, sanitary sewerage, gas and petroleum pipelines, fuel storage, electrical generation and distribution, natural gas extraction, fire-safe homes, tall buildings, stress-strain relationships of steel, bridges, roadways, traffic signals, basic plumbing...

[sublime1996525]

Originally Posted by Yadkin

It's shocking about how little people know about the basic infrastructure that allows civilization to exist: water supply, sanitary sewerage, gas and petroleum pipelines, fuel storage, electrical generation and distribution, natural gas extraction, fire-safe homes, tall buildings, stress-strain relationships of steel, bridges, roadways, traffic signals, basic plumbing...

Why would most people need to know about tall buildings, stress-strain relationships of steel, bridges, natural gas extraction, pipelines, ect?

[dvarapala]

Originally Posted by Egnalf

talking about people or things "spanking" each other on the internet speaks of low character.

People who do it should be spanked.

[dvarapala]

Originally Posted by Yadkin

...sanitary sewerage...

Don't you mean "septage?"

[Yadkin]

Originally Posted by sublime1996525

Why would most people need to know about tall buildings, stress-strain relationships of steel, bridges, natural gas extraction, pipelines, ect?

They don't. Which is my point. The professionals that designed and built all that have done such a great job that the public uses it every day without giving it a second thought.

[Yadkin]

Originally Posted by dvarapala

Don't you mean "septage?"

What's funny is that you don't realize, still, that they are two very different things.

[Steve_R]

Originally Posted by Yadkin

Modeling and hand calculations. Full-scale mock-ups. Checks and testing to failure.

I learned nuclear engineering on a slide rule because we weren’t allowed to use those new-fangled calculators. I still have it, I could draw a straight line with it now.

[Phred) What software did your slide rule run? [/Phred]

[snide]

Originally Posted by sublime1996525

Why would most people need to know about tall buildings, stress-strain relationships of steel, bridges, natural gas extraction, pipelines, ect?

Why would people need to know how to spell "etc"?

[JRD77VET]

Originally Posted by GrandSportC3

It's shocking how little people seem to know about the software life cycle.

1) The product person (or engineer) requests a certain feature
2) The Business Analyst and Development leads meet with the product person to work on requirements for the software to be built. They create a business requirement document.

2A) Idea deemed to outdated but management plows ahead away

3) Development lead and business analyst meet and determine what programs or routines have to be created. This is to be discussed with the development team. The work is broken down and each component is assigned to developers. If this is a larger undertaking, each developer has to create a technical design which is then reviewed with BA and the tech team. Once all agree that the tech design is good, each developer will work on their piece and unit tests their piece.
4) once code and unit test is peer reviewed, it is moved to the QA team (Quality Assurance). All the programs for thr project are tested together. A SIT (System Integration Test) is performed and all potential scenarios are run through the system. If all the test cases are closed and successful, the software will then implemented in production or in case of car software, sent via update to the cars.

I've been a Software Engineer for like 35 years. I work for a huge financial institution and I know very little about banking, yet, I write programs for the bank. I don't need to have banking knowledge. That's what we have the BA's for.

Fixed it for you

My step dad designed computers and explained that to me in the early 80s when he worked for Compac.

By the time you get your idea down on paper, it's already obsolete but the bosses decide when obsolete idea to build.

[Yadkin]

Originally Posted by Steve_R

I learned nuclear engineering on a slide rule because we weren’t allowed to use those new-fangled calculators. I still have it, I could draw a straight line with it now.

[Phred) What software did your slide rule run? [/Phred]

We had to use slide rules in high school chemistry, circa 1976 and '77. I was OK with it but keeping track of the zeroes was a pain in the ass. A basic calculator was too much money for schools or most students (although a friend of mine had one).

Then the TI-30 came out for about thirty bucks and I got one for college. I wore three of them out until I paid five weeks part-time pay for an HP-41CV in '82. If I had to use a slide rule I probably would have taken up something far more simple, like computer programming.

[sublime1996525]

Originally Posted by snide

Why would people need to know how to spell "etc"?

Doh!

[MadInNc]

Best gift under tree

[GrandSportC3]

Originally Posted by JRD77VET

Fixed it for you

My step dad designed computers and explained that to me in the early 80s when he worked for Compac.

By the time you get your idea down on paper, it's already obsolete but the bosses decide when obsolete idea to build.

Not quite like that in our line of business. It's usually driven by users who go to the product owner to request certain features. Product owner then goes to Tech Leads and BA's to discuss what it would take to do the project and they pass the cost to the requestor. If they approve, the project is scheduled and tasks are assigned. It's pretty fast moving. How long it takes from request to completion really depends on our workload but it's usually a fairly quick turnaround. While there are times that we are pretty busy, IT is really a business full of bullshitters. The time we quote for the project is usually many times the time it actually takes.
Recently, my manager's manager talked to me about a project and asked me how much work it would be. I told him that I can do it in probably a day, so I'm going to quote 2 weeks with testing (1 sprint) and a week for QA to test it. He ended up telling the product owner that it will take 5 weeks. I love my management. They really are on our side in my line of business. We have plenty of time to get things done. They appreciate my honesty when I tell them the time it really takes but we always quote much more just in case that we run into anything unexpected.
On average, most of my assigned task for a sprint (a sprint in Agile is 2 weeks of work) can be done in 1/5 of the time that we quote.. Sometimes, the discrepancy is more.. So, that's the reason why I post a lot on forums during work hours.

[MadInNc]

Originally Posted by GrandSportC3

Not quite like that in our line of business. It's usually driven by users who go to the product owner to request certain features. Product owner then goes to Tech Leads and BA's to discuss what it would take to do the project and they pass the cost to the requestor. If they approve, the project is scheduled and tasks are assigned. It's pretty fast moving. How long it takes from request to completion really depends on our workload but it's usually a fairly quick turnaround. While there are times that we are pretty busy, IT is really a business full of bullshitters. The time we quote for the project is usually many times the time it actually takes.
Recently, my manager's manager talked to me about a project and asked me how much work it would be. I told him that I can do it in probably a day, so I'm going to quote 2 weeks with testing (1 sprint) and a week for QA to test it. He ended up telling the product owner that it will take 5 weeks. I love my management. They really are on our side in my line of business. We have plenty of time to get things done. They appreciate my honesty when I tell them the time it really takes but we always quote much more just in case that we run into anything unexpected.
On average, most of my assigned task for a sprint (a sprint in Agile is 2 weeks of work) can be done in 1/5 of the time that we quote.. Sometimes, the discrepancy is more.. So, that's the reason why I post a lot on forums during work hours.

I’ve run business arms for a conglomerate. Brought high tech to the masses over copper, fiber and wireless while running my business groups. If any body who worked for me sandbagged and never finished project, or padded it by weeks I would FIRE W HOSTILITY. I paid bonuses based on early or on time completion. Your company morals are to question and KPIs are not aligned for growth.

Who you work for is STUPID. Instead on finishing program in your projections, they missed taking on another program or customer.

If ya doubt what I say. PM me

[Yadkin]

Originally Posted by GrandSportC3

Not quite like that in our line of business. It's usually driven by users who go to the product owner to request certain features. Product owner then goes to Tech Leads and BA's to discuss what it would take to do the project and they pass the cost to the requestor. If they approve, the project is scheduled and tasks are assigned. It's pretty fast moving. How long it takes from request to completion really depends on our workload but it's usually a fairly quick turnaround. While there are times that we are pretty busy, IT is really a business full of bullshitters. The time we quote for the project is usually many times the time it actually takes.
Recently, my manager's manager talked to me about a project and asked me how much work it would be. I told him that I can do it in probably a day, so I'm going to quote 2 weeks with testing (1 sprint) and a week for QA to test it. He ended up telling the product owner that it will take 5 weeks. I love my management. They really are on our side in my line of business. We have plenty of time to get things done. They appreciate my honesty when I tell them the time it really takes but we always quote much more just in case that we run into anything unexpected.
On average, most of my assigned task for a sprint (a sprint in Agile is 2 weeks of work) can be done in 1/5 of the time that we quote.. Sometimes, the discrepancy is more.. So, that's the reason why I post a lot on forums during work hours.