Never bad to read for the below:
http://opendatastructures.org/
( Ahhh good old university memories :) Fun Fun Fun)
Majed A
http://majedline.blogspot.com
Wednesday, May 9, 2012
Wednesday, May 2, 2012
Best Developer and Best QA.
Today I had a thought, how can you define 'the best' developer and QA?
( Any rebuttals are welcome )
As a developer, I rely on the fact that my classes, functions, methods, etc.. use my colleague's libraries, classes, properties, functions etc.... So I have to trust my colleague in doing the necessary work to help me and vica-versa. If I don't, I would end up doing the work all by myself and duplicating what he/she did, and we all know that this is never good idea as it will cause more problems in the long run ( and the owners won't be happy about the wasted money)
Now in regard to the fellow QAs; if I the developer don't trust them then that means I have to test my work to ensure things are good. And by test, I want to do all that I could do to not get bugs from the QAs as much as possible in a legit way ( No cheating here and doing patch work to hide bugs!!). And we all know that tested code before reaching the QAs are most successful. Even if you ignore the fact that the developer implemented something in the most convoluted way, if it works.. It works! ( Do I sound like a PM now or what ).
To be fair, I'll add one more rule regarding the above; code should never be more than an order magnitude O(N^2)]. Otherwise in the long run, it'll take forever doing anything.
As a QA, the same argument applies. I as a QA cannot do all the testing. I have to rely on my QA colleague to test all areas and functionality that I would use in my areas and vica-versa. Otherwise I won't be sleeping the night doing all the work myself.
In regards to not trusting the developer, well if I do, then why bother doing the work? If I don't I will do my best to find a bug. And by bug, I mean a legit bug, not 'this is a pink background, not off pink as required'.
So how did I come to this conclusion you ask? Experience as all the above and PM/Scrummaster! I have seen the most experienced Devs. come up with some amazingly designed untested code. It ended up being littered with bugs and took twice as long to release. On the other hand, an average dev provided the QAs with tested code, it took half the time in testing, was ready ahead of schedule and caused the QAs to focus on hard bugs. The same goes for QAs. Those who trusted the work of the developers, ended up sleeping on the job (literally). Those who didn't, found some amazing loopholes and bugs no one would have thought off.
You combine both together, an 'untrusting' developer with an 'untrusting' QA, and you will end up with production ready code in no time.
Majed A
http://majedline.blogspot.com
( Any rebuttals are welcome )
- Developer- one who trusts the work of his developer colleague, but not the QA's work.
- QA - one who trusts the work of his QA colleague, but not the developer's work.
As a developer, I rely on the fact that my classes, functions, methods, etc.. use my colleague's libraries, classes, properties, functions etc.... So I have to trust my colleague in doing the necessary work to help me and vica-versa. If I don't, I would end up doing the work all by myself and duplicating what he/she did, and we all know that this is never good idea as it will cause more problems in the long run ( and the owners won't be happy about the wasted money)
Now in regard to the fellow QAs; if I the developer don't trust them then that means I have to test my work to ensure things are good. And by test, I want to do all that I could do to not get bugs from the QAs as much as possible in a legit way ( No cheating here and doing patch work to hide bugs!!). And we all know that tested code before reaching the QAs are most successful. Even if you ignore the fact that the developer implemented something in the most convoluted way, if it works.. It works! ( Do I sound like a PM now or what ).
To be fair, I'll add one more rule regarding the above; code should never be more than an order magnitude O(N^2)]. Otherwise in the long run, it'll take forever doing anything.
As a QA, the same argument applies. I as a QA cannot do all the testing. I have to rely on my QA colleague to test all areas and functionality that I would use in my areas and vica-versa. Otherwise I won't be sleeping the night doing all the work myself.
In regards to not trusting the developer, well if I do, then why bother doing the work? If I don't I will do my best to find a bug. And by bug, I mean a legit bug, not 'this is a pink background, not off pink as required'.
So how did I come to this conclusion you ask? Experience as all the above and PM/Scrummaster! I have seen the most experienced Devs. come up with some amazingly designed untested code. It ended up being littered with bugs and took twice as long to release. On the other hand, an average dev provided the QAs with tested code, it took half the time in testing, was ready ahead of schedule and caused the QAs to focus on hard bugs. The same goes for QAs. Those who trusted the work of the developers, ended up sleeping on the job (literally). Those who didn't, found some amazing loopholes and bugs no one would have thought off.
You combine both together, an 'untrusting' developer with an 'untrusting' QA, and you will end up with production ready code in no time.
Majed A
http://majedline.blogspot.com
Subscribe to:
Posts (Atom)