IT/Software career thread: Invert binary trees for dollars.

Khane

Got something right about marriage
19,931
13,472
I'm not sure why people get the attitude of chosing whether to blame the tester or the creator for a problem that exists in the creation. It's both people's fault.
This is true. God I wish we had QA staff here. No seriously, we have no QA staff.
 

Lendarios

Trump's Staff
<Gold Donor>
19,360
-17,424
OMG today. another endless opinion argument.

Same Xml guy: Oh whenever i do an db save, i reload all my data from the DB, and return that.
Me: why will you do that? there are no errors, no exceptions, why will u do another call to the DB, when no errors where detected during the save operation.

Same Xml guy: Oh just to be sure, What if the database now takes the data and manipulates it on a trigger, then resaves it.
Me: that is why i dont put busines logic into the database. Besides No ORM out there does a load after doing an inster/update, they just return the object, minus properties that are changed on the DB such as identities.
Same Xml guy: THat si not true, you dont know all of them.
Me, true, i know Entity framework, and Entity framework, does not do a select after doing an insert/update. That is just extra work for nothing.

Same Xml guy: What if you have two separate applications where one modifies the other data. But after the operation have been defined as a read only operation, THEN the second application now starts changing your data without telling the first application., Don't you want that?
Me: no, if an operation has been defined as read only, then after that unilaterally the receiving side decides to change the data and send it back, the first application must be explicitly changed. It cant just take the data. An application has to be responsible for its own data, and don't rely on other applications for changes on it. If they do rely on others then it must be explicit. Imagine if I have an object with Address properties, now the second application combines address line 1 and address line 2, into 1. As far as the first application is concerned, that change should not affect the data on application 1, and if the change is OK, then app 1 must be now changed.
Same Xml guy: well its just a matter of opinion.
Me: Ok. find me an orm that does that. until then Im going with EF and microsoft opinion on this one.
 

Khane

Got something right about marriage
19,931
13,472
Nothing is worse than someone who argues baseless hypotheticals as if it's assured to happen one day. Especially if it's hypotheticals based around software your company doesn't even use.

Actually one thing is worse. Someone who actually tries to code for every possible outcome and thinks that generic means modular.

"But what if we want to re-use this, it needs to be typeless and stateless and account for anything we might throw at it!"
"No, just make specific pieces of modular code that you can re-use, you're trying to make a rube goldberg machine"
"No, this will save us time in the long run"
"Useless functionality that will never be used doesn't save anyone any time and makes everything far more complex than it needs to be"
 

Vinen

God is dead
2,783
490
This is true. God I wish we had QA staff here. No seriously, we have no QA staff.
Why? Is your development team too terrible to do their job? QA is just to validate that requirements are met. In a perfect world we shouldnt' find any bugs.
 

Noodleface

A Mod Real Quick
37,961
14,508
Man nothing like that feeling of spending a week on a pretty large task only to have it finally click at 5PM on friday. Thought I'd have to work over the weekend.
 

Vinen

God is dead
2,783
490
Man nothing like that feeling of spending a week on a pretty large task only to have it finally click at 5PM on friday. Thought I'd have to work over the weekend.
Had this happen too. Hell yeah getting RSA SecurID working as an Authentication avenue.
 

Khane

Got something right about marriage
19,931
13,472
Why? Is your development team too terrible to do their job? QA is just to validate that requirements are met. In a perfect world we shouldnt' find any bugs.
Hahaha. Well in a perfect world we would also get to set our own deadlines, be given the time and resources to architect the software appropriately for the task it's meant to perform, and be able to say no to absolutely assinine requirements that make no sense. We'd also have a much bigger team.

Software Developers are notoriously bad at testing their own code. We say shit like "Well nobody is ever going to use it that way anyway" and a lot of times requirements and business needs get lost in translation. QA staff is necessary in the real world.
 

Vinen

God is dead
2,783
490
Hahaha. Well in a perfect world we would also get to set our own deadlines, be given the time and resources to architect the software appropriately for the task it's meant to perform, and be able to say no to absolutely assinine requirements that make no sense. We'd also have a much bigger team.

Software Developers are notoriously bad at testing their own code. We say shit like "Well nobody is ever going to use it that way anyway" and a lot of times requirements and business needs get lost in translation. QA staff is necessary in the real world.
I don't get the last part. Why are you terrible at testing your code? You should be the best at it. You understand exactly what is written.

I know many developer organizations which function with ZERO quality assurance.

Take TripAdvisor. Search for how many QE/QA jobs they have.
Careers at TripAdvisor

Notice quality is in all the Dev reqs?
 

Hachima

Molten Core Raider
884
638
The scenario that the developer didn't consider when implementing the feature will be the same scenario they don't think to test for. A TDD approach can help because it forces the developer to take step back and take more consideration in the potential scenarios. Pair programming, code reviews, static code analysis, model checking, runtime analysis, bug seeding activities etc all help in this. QA teams are another way to help improve the end product. To consider any one practice a silver bullet would be foolish.

The higher the criticality of the project, the more of these practices should be taken into consideration and more effort put into them. You have to consider loss of life/pain, loss of all of an entity's money/partial money loss.

Finding bugs by developers in pair programming, CI, code reviews is going to be cheaper than QA finding the bugs. Even more expensive is when your customers find bugs after a release. Further down the line the developers responsible for fixing the issue are further away from working in that area and are going to be distracted from other work they are doing, reducing their efficiency on that new work. There is also more overhead the further down the line with support staff/bug tracking etc. Well maybe not if you are are able to sell support plans to your customers at a premium to address the issues
smile.png
Still there is only so much they put up with before they seek alternative solutions or a competitor sees room to improve and compete if that's the plan.
 

Vinen

God is dead
2,783
490
The scenario that the developer didn't consider when implementing the feature will be the same scenario they don't think to test for. A TDD approach can help because it forces the developer to take step back and take more consideration in the potential scenarios. Pair programming, code reviews, static code analysis, model checking, runtime analysis, bug seeding activities etc all help in this. QA teams are another way to help improve the end product. To consider any one practice a silver bullet would be foolish.

The higher the criticality of the project, the more of these practices should be taken into consideration and more effort put into them. You have to consider loss of life/pain, loss of all of an entity's money/partial money loss.

Finding bugs by developers in pair programming, CI, code reviews is going to be cheaper than QA finding the bugs. Even more expensive is when your customers find bugs after a release. Further down the line the developers responsible for fixing the issue are further away from working in that area and are going to be distracted from other work they are doing, reducing their efficiency on that new work. There is also more overhead the further down the line with support staff/bug tracking etc. Well maybe not if you are are able to sell support plans to your customers at a premium to address the issues
smile.png
Still there is only so much they put up with before they seek alternative solutions or a competitor sees room to improve and compete if that's the plan.
I've tried and failed about 100 times to get pair programming implemented at my current job.

Fuck, just grabbing a second person to look at it from a functional level before you check-in requires teeth pulling.
 

ShakyJake

<Donor>
7,678
19,348
The problem we have is, considering the whole developer / QA thing, is that neither understands the domain logic.

It's like,

product owner: "hey, we need you to add an additional safety check to our nuclear reactor controller software."

dev: "Yeah, but I don't understand how the current system works or one iota of nuclear physics".

tester: -looks blankly on-

product owner: "yeah, well, figure it out."
 

Vinen

God is dead
2,783
490
The problem we have is, considering the whole developer / QA thing, is that neither understands the domain logic.

It's like,

product owner: "hey, we need you to add an additional safety check to our nuclear reactor controller software."

dev: "Yeah, but I don't understand how the current system works or one iota of nuclear physics".

tester: -looks blankly on-

product owner: "yeah, well, figure it out."
I don't understand how someone can work on a product without being an expert on what they are developing. This is a severe issue I've seen cause problems at many companies.

As in the company makes somewhere between zero and no effort to attempt to bring a new employee (be it QE,Dev or even PM roflz) up to speed on what they are working on. I mean... even the goal of the product.
 

Tenks

Bronze Knight of the Realm
14,163
606
Because companies are broad and developers can't be an expert on anything? I just got reassigned to a high priority project which is basically an ingest service for data which basically decorates a master record. So we have record#1 in our database and members can add some additional/modify information with these records which are only for them. I know what they are. I know their purpose but I'm far from an expert on how we currently ingest them on our mainframe and I'm not an expert on the shortcomings of the current implementation in both online and batched via MapReduce. But I'm still on the project and I'm still expected to contribute right away. It seems silly to expect every developer to have expert domain knowledge on the problem that is why the SMEs and well defined requirements exist.
 

Lendarios

Trump's Staff
<Gold Donor>
19,360
-17,424
The main reason why developers don't like to QA, is simply laziness. To get people to write a test is like pulling teeth.
 

moontayle

Golden Squire
4,302
165
I don't understand how someone can work on a product without being an expert on what they are developing. This is a severe issue I've seen cause problems at many companies.

As in the company makes somewhere between zero and no effort to attempt to bring a new employee (be it QE,Dev or even PM roflz) up to speed on what they are working on. I mean... even the goal of the product.
I had that to look forward to before things fell apart right before I started. And to their credit my director did everything he could to teach me about what we do here, but in the end I have zero people to turn to when I run into an issue with the code. At best I can bounce ideas off the senior dev but she knows very little about the platform I'm attached to.

But hey, if they're going to pay me to fumble around in the dark until I can get something working, I'll play along.
 

Tuco

I got Tuco'd!
<Gold Donor>
45,525
73,615
OMG today. another endless opinion argument.

Same Xml guy: Oh whenever i do an db save, i reload all my data from the DB, and return that.
Me: why will you do that? there are no errors, no exceptions, why will u do another call to the DB, when no errors where detected during the save operation.

Same Xml guy: Oh just to be sure, What if the database now takes the data and manipulates it on a trigger, then resaves it.
Me: that is why i dont put busines logic into the database. Besides No ORM out there does a load after doing an inster/update, they just return the object, minus properties that are changed on the DB such as identities.
Same Xml guy: THat si not true, you dont know all of them.
Me, true, i know Entity framework, and Entity framework, does not do a select after doing an insert/update. That is just extra work for nothing.

Same Xml guy: What if you have two separate applications where one modifies the other data. But after the operation have been defined as a read only operation, THEN the second application now starts changing your data without telling the first application., Don't you want that?
Me: no, if an operation has been defined as read only, then after that unilaterally the receiving side decides to change the data and send it back, the first application must be explicitly changed. It cant just take the data. An application has to be responsible for its own data, and don't rely on other applications for changes on it. If they do rely on others then it must be explicit. Imagine if I have an object with Address properties, now the second application combines address line 1 and address line 2, into 1. As far as the first application is concerned, that change should not affect the data on application 1, and if the change is OK, then app 1 must be now changed.
Same Xml guy: well its just a matter of opinion.
Me: Ok. find me an orm that does that. until then Im going with EF and microsoft opinion on this one.
Did you try the, "If you're concerned that a given database is modifying your data after a save, why don't you unit test for that and keep the recheck out of the customer facing software?".

As for QA testing software, I'd rather they focus on testing stuff at a system or integration level. I'd love it if QA had the capacity to write unit tests and be involved at that level, but it's an incredible amount of work for them to do.