I guess that anything that helps you find problems before you start is a
The customer ; )
Not when they recieve the bill.
And rightly so. Not testing (or developing using a credible life cycle
If quality doesn't matter. Speed to market with a dud product that ends up
As opposed to the gradutes and cowboys who can deliver even less efficient
Where quality doesn't matter.Common with application level software written by "software
departments", but in practice rarely used on the small micro level.
Dave
RaVc.26033$%r.287266@nasal.pacific.net.au...just takes a mind-set. Which, I admit, I don't always have - it takes a bit"David L. Jones" <tronnort@yahoo.com> wrote in message
news:cfgvg0$506@odak26.prod.google.com...
Depends on the job.
If it's a big high profile mission critical job and you have the time
to do it then it's a serious option, or more often just an essential
requirement dictated from higher up.
And rightly so. Not testing (or developing using a credible life cycle
development methodology) for mission critical systems is not appropriate.
If
it is mission critical then it has to be robust.
But more often than not it's a waste of time and most people don't
bother, development times are too short these days.
If quality doesn't matter. Speed to market with a dud product that ends up
having buckets of money and time poured in to fix it up is not uncommon -
but it reflects on the lack of professionalism of the organisation.
It's also a popular way for a bad or just plain slow and inefficient
programmers to justify a job that takes 10 times longer than a good
talented programmer who knows what they are doing :-
As opposed to the gradutes and cowboys who can deliver even less efficient
code 10 times faster but with a total lack of respect for performance,
processing costs or future maintenance capability ;-|
Common with application level software written by "software
departments", but in practice rarely used on the small micro level.
Dave
Where quality doesn't matter.
It's not really all that hard to build test functions into your code, it
As you say though, it produces better qualityIt can also be a complete waste of time if your code is only small"Wayne Reid" <REMOVEgokangas@hotmail.com> wrote in message
news
"David L. Jones" <tronnort@yahoo.com> wrote in message
news:cfgvg0$506@odak26.prod.google.com...
Depends on the job.
If it's a big high profile mission critical job and you have the time
to do it then it's a serious option, or more often just an essential
requirement dictated from higher up.
And rightly so. Not testing (or developing using a credible life cycle
development methodology) for mission critical systems is not appropriate.
If
it is mission critical then it has to be robust.
But more often than not it's a waste of time and most people don't
bother, development times are too short these days.
If quality doesn't matter. Speed to market with a dud product that ends up
having buckets of money and time poured in to fix it up is not uncommon -
but it reflects on the lack of professionalism of the organisation.
It's also a popular way for a bad or just plain slow and inefficient
programmers to justify a job that takes 10 times longer than a good
talented programmer who knows what they are doing :-
As opposed to the gradutes and cowboys who can deliver even less efficient
code 10 times faster but with a total lack of respect for performance,
processing costs or future maintenance capability ;-|
Common with application level software written by "software
departments", but in practice rarely used on the small micro level.
Dave
Where quality doesn't matter.
It's not really all that hard to build test functions into your code, it
just takes a mind-set. Which, I admit, I don't always have - it takes a bit
more effort to do.
product.
Ken
The quite valid point being along the lines of right tool for the job......"Ken Taylor" <ken123@xtra.co.nz> wrote in message
news:<2ol6jtFbb1gjU1@uni-berlin.de>...
"Wayne Reid" <REMOVEgokangas@hotmail.com> wrote in message
news
"David L. Jones" <tronnort@yahoo.com> wrote in message
news:cfgvg0$506@odak26.prod.google.com...
Depends on the job.
If it's a big high profile mission critical job and you have the
time
to do it then it's a serious option, or more often just an essential
requirement dictated from higher up.
And rightly so. Not testing (or developing using a credible life cycle
development methodology) for mission critical systems is not
appropriate.
If
it is mission critical then it has to be robust.
But more often than not it's a waste of time and most people don't
bother, development times are too short these days.
If quality doesn't matter. Speed to market with a dud product that
ends up
having buckets of money and time poured in to fix it up is not
uncommon -
but it reflects on the lack of professionalism of the organisation.
It's also a popular way for a bad or just plain slow and inefficient
programmers to justify a job that takes 10 times longer than a good
talented programmer who knows what they are doing :-
As opposed to the gradutes and cowboys who can deliver even less
efficient
code 10 times faster but with a total lack of respect for performance,
processing costs or future maintenance capability ;-|
Common with application level software written by "software
departments", but in practice rarely used on the small micro level.
Dave
Where quality doesn't matter.
It's not really all that hard to build test functions into your code, it
just takes a mind-set. Which, I admit, I don't always have - it takes a
bit
more effort to do.
product.
Ken
It can also be a complete waste of time if your code is only small
and/or simple and fully testable within your actual application. It
will also mean extra code that can force you into a more expensive
micro solution which can mean big $$$$$$ if you are into high volume.
Test driven development is not a universal solution, it will always
depend on the circumstances.
We had a classic situation a few months back. We needed something
within a day or two to meet a critical deadline. We were quoted 3
weeks+ by the software department who wanted to implement the proper
software development cycle etc etc. I said bugger that and wrote it in
two hours, fully tested in the actual application in another hour or
two. Deadline met, customer happy, and a quality product 100% proven
by full application testing. Yes, we documented it later. Some markets
demand ridiculous deadlines.
Dave