Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Re: Re: de-inventing the wheel (discussion)by dragonchild (Archbishop) |
on Jun 21, 2001 at 21:16 UTC ( [id://90465]=note: print w/replies, xml ) | Need Help?? |
There's more to it than that. There is a very significant portion of managers, who oversee either programmers or managers who do so, to whom testing is a "waste of time and money" because "it doesn't add value" to the code. Their concept is that there is a right way to write code and, since they're paying a large sum of money for the programmers, they should get it right the first time. And, in a weird way, that position is a fair one.
However, that position is only defensible if the programmers have the following characteristics:
So, testing, especially regression suites, become extremely important. However, to write a solid regression suite is a project in and of itself. By its very nature, you cannot have the programmer(s) write it. They don't know enough about the requirements and they know too much about the implementation. You should never have the programmer(s) sign off on the testing, anyways. They know too much about the code. Testing, imho, should be (primarily) black-box testing. Programmers, by their nature, do white-box testing, which is good, but isn't stringent enough for release sign-off. That said, upgrading should be easy if the programmers were able to write the application in a modular enough fashion. Upgrades very rarely affect more than two or three logical sections of an application. The problem with upgrades is that those logical sections have historically never been separated out. Not even with OO code. (I worked on a project which had objects, but encapsulation was violated left and right.) There needs to be better design and requirements. If that is done, better coding will necessarily follow. Bad requirements => Bad design => Bad code => No upgrading.
In Section
Meditations
|
|