Course in Software Engineering

[SpontaneousOrder]

And for what it is worth about 95% of what you do in an Engineering degree is centuries old.

And less than 7 decades ago software didn't even exist. So you're kindof highlighting my point.

[minestrone]

And less than 7 decades ago software didn't even exist. So you're kindof highlighting my point.

Hmm no.

The main thrust of all of my posts on this thread ( you clearly are too unable to actually understand ) and the one we initially disagreed on was that the lack of formal design training in software is to the detriment of the industry.

What did you do a degree in?

[minestrone]

And less than 7 decades ago software didn't even exist. So you're kindof highlighting my point.

And you are wrong on that as well...

https://en.wikipedia.org/wiki/Jacquard_loom

[tractor]

....

The strength of a formal engineering degree is that you are told to go through a number of designs before even approaching a possible solution.

50% of a mechanical degree is working on Newton's laws yet modern Engineers had somehow moved past being stuck thinking the steam engine is the absolute of the highlight of the branch of the science.

The concept of try, fail, learn, retry is completely accepted in science and engineering but will not be even accepted in software.

Until that changes software will never be considered an Engineering science.

It's not about the technology, it's about the way people work with the technology.

Half of the problems coders encounter are the result of organisations attempting to apply engineering rigour to conceptual design/development. Aside from IC and other manufacturing, trying to apply 6 Sigma, CMMI and all the other periodically in vogue Japanese/American manufacturing methodologies/concepts to software development is absolutely the wrong way to go. They are heavily steeped in the 'try, fail, learn, retry ' cycle you mention. It doesnt help much though.

The biggest problem we face is expecting an individual to deliver much of the product from inception to decommission. How many times do you see a JS advert that requires an experience list as long as the OP's course list? All the time. How many people do you know who have that level of deep experience and knowledge throughout the development process?

Those are just some of the reasons tulip is produced. It has little to do with formalised education or having letters after ones' name.

The solution is simple. Specification, specification, specification. From the Boardroom to the User Guides, that is usually what is sorely lacking, mainly because it costs money. Far cheaper just to throw pair programmers at it after their morning stand up.

EDIT:

The title 'engineer' is not protected by law in the UK but that was what I thought 'Chartered' was for. Those titles are protected by law.

[SpontaneousOrder]

Hmm no.

The main thrust of all of my posts on this thread ( you clearly are too unable to actually understand ) and the one we initially disagreed on was that the lack of formal design training in software is to the detriment of the industry.

You can't have formal training in design when we don't yet know what good design, in a canonical sense, looks like.

What did you do a degree in?

Software Engineering.

[SpontaneousOrder]

And you are wrong on that as well...

https://en.wikipedia.org/wiki/Jacquard_loom

From your own source:

The ability to change the pattern of the loom's weave by simply changing cards was an important conceptual precursor to the development of computer programming and data entry.

Computer software or simply software is any set of machine-readable instructions that directs a computer's processor to perform specific operations.

[tractor]

...

From your own source:

Indeed, the weaving example was more akin to automation than computing.

And computing is more aligned with applied maths than engineering IMO but it will always be called software 'engineering'.

[minestrone]

You can't have formal training in design when we don't yet know what good design, in a canonical sense, looks like.

Jesus Christ, you truly are a complete mental deficient.

As I have advocated through this thread repeatedly, like a cricket bat to your head repeatedly, the process of design, the process.

I give up.

[SpontaneousOrder]

Half of the problems coders encounter are the result of organisations attempting to apply engineering rigour to conceptual design/development. Aside from IC and other manufacturing, trying to apply 6 Sigma, CMMI and all the other periodically in vogue Japanese/American manufacturing methodologies/concepts to software development is absolutely the wrong way to go. They are heavily steeped in the 'try, fail, learn, retry ' cycle you mention. It doesnt help much though.

The biggest problem we face is expecting an individual to deliver much of the product from inception to decommission. How many times do you see a JS advert that requires an experience list as long as the OP's course list? All the time. How many people do you know who have that level of deep experience and knowledge throughout the development process?

Those are just some of the reasons tulip is produced. It has little to do with formalised education or having letters after ones' name.

The solution is simple. Specification, specification, specification. From the Boardroom to the User Guides, that is usually what is sorely lacking, mainly because it costs money. Far cheaper just to throw pair programmers at it after their morning stand up.

EDIT:

The title 'engineer' is not protected by law in the UK but that was what I thought 'Chartered' was for. Those titles are protected by law.

Bob martin raises a good point too - that the number of programmers doubles every (can't remember but not many) years, and will do up to a certain point probably not too far away.

That means, by definition, that the VAST majority of all programmers are, and always have been so far, relatively junior. The market grows exponentially, the supply of programmers grows exponentially to meet that demand, and consequently the concentration of experience decreases at the same rate.

He also says we need to become real engineers - before some terrible incident kills a bunch of people and the government regulates us all to hell.

But we need to proactively get good at this as an industry in order to get to that point (and the best of us currently are still not there yet - we're industrial toddlers right now), which is an idea he promotes alot with his drives at 'craftsmanship' etc - codifying our current standards in formal qualifications is the exact opposite of what's needed, because - as Sam Newman said in the book I quoted - no one actually knows yet what 'good' actually looks like. We just know not to do things that didn't work out well before.

[tractor]

....

Bob martin raises a good point too - that the number of programmers doubles every (can't remember but not many) years, and will do up to a certain point probably not too far away.

That means, by definition, that the VAST majority of all programmers are, and always have been so far, relatively junior. The market grows exponentially, the supply of programmers grows exponentially to meet that demand, and consequently the concentration of experience decreases at the same rate.

He also says we need to become real engineers - before some terrible incident kills a bunch of people and the government regulates us all to hell.

But we need to proactively get good at this as an industry in order to get to that point (and the best of us currently are still not there yet - we're industrial toddlers right now), which is an idea he promotes alot with his drives at 'craftsmanship' etc - codifying our current standards in formal qualifications is the exact opposite of what's needed, because - as Sam Newman said in the book I quoted - no one actually knows yet what 'good' actually looks like. We just know not to do things that didn't work out well before.

Take it further with standards and ISO 9000 gives us a guarantee that we followed a process but no guarantee that anything works at the end.

CASE can often lower the bar rather than raise it too.

This is why analysts and testers (V model) are so valuable but the way things are going, rates for PMO staff have overtaken them quite alarmingly.