Course in Software Engineering

[SpontaneousOrder]

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.

You can replace 'the design' with 'the process of design' if you like. The point still stands.



TDD is considered the defacto standard for professional developers now, in most programming domains, by pretty much anyone considered 'expert' in the subject.

10 years ago, probably less than 1% of developers did TDD.

I would expect that today less than 1% of software related degree course teach TDD.

That's a seismic shift if the approach to 'good' design process at a low level, and the same shift has occurred significantly at higher levels too.


Of course, TDD doesn't help much when writing one giant monolith in a single method on a single class

[minestrone]

TDD is a farce, it only encourages poor design.

Quality is signed off now on how many test there are, not on how good the code is.

50% of code on most systems is test based now, if they just let programmers that time to train and learn then they would need less testing.

As Deming said...

"Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place."

[SpontaneousOrder]

TDD is a farce, it only encourages poor design.

Quality is signed off now on how many test there are, not on how good the code is.

50% of code on most systems is test based now, if they just let programmers that time to train and learn then they would need less testing.

As Deming said...

"Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place."

Thanks for the laugh.
Now go and learn what TDD is, because everything you said there, including the quote! makes it sound like you've got the wrong end of the stick.

And TDD aside (TDD isn't about testing), how are you going to make changes to your code when requirements change, confidently (and without that confidence you'll hack your changes in to keep changes minimal, instead of refactoring appropriately so that the code remains maintainable), without all of those unit tests as a safety net to catch you making mistakes?

Are you going to automate every possible end-to-end test permutation? And apart from costing millions to do that, how do you get around the fact that your regression suite now tales half a day to run?

Or are you going to pay a small army of manual testers to click their way through every possible scenario to make sure there aren't any regressions? And then you're talking about weeks instead of half a day.

So what happens when a bug is discovered in production, and it takes a whole day (or fortnight) to identify, fix, test, and release back to production?

And of course, as I mentioned, all of that's just in relation to testing. Let alone TDD.

[zemoxyl]

I said that 'engineering' is a rubbish analogy, but the best we have in a such a immature industry - and you cite someone (an academic of all people) using the only word we have to describe his craft, as evidence that the analogy is accurate?

The point being that the thread is about software engineering at Oxford. Courses are so titled throughout the world in thousands of educational establishments - even in those countries where the term 'engineer' is legally protected. It has been this way for thirty or forty years.

You think the term is a poor reflection of what the course contents really are and what they teach. As you claim to have a software engineering degree yourself, perhaps you'd care to explain why the training and implementation is not well defined as 'engineering'.

So go on, give us a better definition...................

[SpontaneousOrder]

The point being that the thread is about software engineering at Oxford. Courses are so titled throughout the world in thousands of educational establishments - even in those countries where the term 'engineer' is legally protected. It has been this way for thirty or forty years.

You think the term is a poor reflection of what the course contents really are and what they teach. As you claim to have a software engineering degree yourself, perhaps you'd care to explain why the training and implementation is not well defined as 'engineering'.

So go on, give us a better definition...................

Read Sam Newman's quote I posted a page or 2 back.
That's exactly why I think it's absurd to think of ourselves as 'real' engineers - and exactly why I think it's reasonable to call ourselves engineers.

[minestrone]

Thanks for the laugh.
Now go and learn what TDD is, because everything you said there, including the quote! makes it sound like you've got the wrong end of the stick.

And TDD aside (TDD isn't about testing), how are you going to make changes to your code when requirements change, confidently (and without that confidence you'll hack your changes in to keep changes minimal, instead of refactoring appropriately so that the code remains maintainable), without all of those unit tests as a safety net to catch you making mistakes?

Are you going to automate every possible end-to-end test permutation? And apart from costing millions to do that, how do you get around the fact that your regression suite now tales half a day to run?

Or are you going to pay a small army of manual testers to click their way through every possible scenario to make sure there aren't any regressions? And then you're talking about weeks instead of half a day.

So what happens when a bug is discovered in production, and it takes a whole day (or fortnight) to identify, fix, test, and release back to production?

Including the quote?

I'm trying to give you mental midgets in software an education in why you will never be regarded as a real Engineering science.

You can laugh at my posts but you are laughing at the man that built Toyota and Sony to world leaders in a 20 years through quality control concepts.

[minestrone]

Read Sam Newman's quote I posted a page or 2 back.
That's exactly why I think it's absurd to think of ourselves as 'real' engineers - and exactly why I think it's reasonable to call ourselves engineers.

You can't be a considered a real engineer, you write some code, you write a few tests to prove that what you write works.

That is not real engineering, it's just you putting on some mascara and looking in the mirror to see if it looks right.

[zemoxyl]

That's exactly why I think it's absurd to think of ourselves as 'real' engineers - and exactly why I think it's reasonable to call ourselves engineers.

That is not real engineering, it's just you putting on some mascara and looking in the mirror to see if it looks right.

Go on then fellas, for all us non-'real' engineers out there, give us the definition of what a 'real' engineer is. You're both pretty forthright in your comments, so enlighten us !!

Any engineer worth his or her salt can define what that is surely ?

[minestrone]

I'm reading some of Deming's works just now and I have really forgotten how much the man has to offer the world of software.

"You can expect what you inspect"

That is exactly why TTD fails.

I'm not against testing software with software, it just does not deliver what every one tells us it delivers.

[SpontaneousOrder]

You can't be a considered a real engineer, you write some code, you write a few tests to prove that what you write works.

That is not real engineering, it's just you putting on some mascara and looking in the mirror to see if it looks right.

It's been a long time since I wrote tests to prove my code works.