It's a push



  • My boss is a reasonably bright guy; very detail oriented. But sometimes he just doesn't think things through.

    He asked me to make a change in the system and to test it on database B (specifically not DB-A because it would break the procs for other developers). But the stored procs in DB-B had a different set of parameters (from another code branch) than the ones in my code branch. But he didn't tell me this. I waited 3 hours for the dba to install some data and update the proc on which I was working, only to find out that every OTHER proc in the system failed because of argument mismatches with the code. Naturally, my test never quite got to my code.

    Upon querying if there was a database that was already set up to match my code branch, he tells me to use DB-A and not to worry about the other developers (we're all under under his control). Sigh.

    On the other hand, he buys the drinks every Friday.

     



  • @snoofle said:

    On the other hand, he buys the drinks every Friday.

    At least you have your priorities straight!

    Can you explain the development process here a little more?  It sounds like you have multiple branches going for the stored procs, but no good way to test them locally.



  • @Justice said:

    Can you explain the development process here a little more?  It sounds like you have multiple branches going for the stored procs, but no good way to test them locally.

     

    Let's see. We have three active development efforts with significant overlap proceeding independently. We have the production branch, and the branch currently being tested for release.

    However, we have 3 databases that are supposed to be for dev, qa and pre-production type testing. Unfortunately, they're used for whatever whomever wants at the moment, so you usually get a hodgepodge of stored procs in varying states of stable/testing/free-for-all-dev, and the only person who knows what featuresin the db will work with which features of the app is this guy.

    We also compile, build and test in prod on live data in preparation for releases. Yeah, I know, but they (users) won't budge on paying for the equipment to do it right.



  • @snoofle said:

    @Justice said:

    Can you explain the development process here a little more?  It sounds like you have multiple branches going for the stored procs, but no good way to test them locally.

     

    Let's see. We have three active development efforts with significant overlap proceeding independently. We have the production branch, and the branch currently being tested for release.

    However, we have 3 databases that are supposed to be for dev, qa and pre-production type testing. Unfortunately, they're used for whatever whomever wants at the moment, so you usually get a hodgepodge of stored procs in varying states of stable/testing/free-for-all-dev, and the only person who knows what featuresin the db will work with which features of the app is this guy.

    We also compile, build and test in prod on live data in preparation for releases. Yeah, I know, but they (users) won't budge on paying for the equipment to do it right.

    So you have separate databases, and you know they're supposed to be used for separate types of testing, but yet you don't enforce this, and you wonder why your shit gets out of sync and doesn't work and testing is a chore? Am I the only one who sees the obvious solution here?

    Also why would you wait for a DBA to load test data for you... every "pure" DBAs I've ever worked with has been absolutely useless (unless they're actually a dev wearing a DBA hat). If the rule is that that sort of shit "has" to be done by a DBA, get the rule changed.



  • @snoofle said:

    <snip />We have three active development efforts with significant overlap proceeding independently. We have the production branch, and the branch currently being tested for release.

    However, we have 3 databases that are supposed to be for dev, qa and pre-production type testing. Unfortunately, they're used for whatever whomever wants at the moment, so you usually get a hodgepodge of stored procs in varying states of stable/testing/free-for-all-dev, and the only person who knows what features in the db will work with which features of the app is apparently nobody, but this guy comes close.

    We also compile, build and test in prod on live data in preparation for releases. Yeah, I know, but they (users) won't budge on paying for the equipment to do it right.

    FTFY.  *cringe*  I much prefer my group's dev environment:

    <snip /> tl;dp

    @The_Assimilator said:

    So you have separate databases, and you know they're supposed to be used for separate types of testing, but yet you don't enforce this, and you wonder why your shit gets out of sync and doesn't work and testing is a chore? Am I the only one who sees the obvious solution here?

    Also why would you wait for a DBA to load test data for you... every "pure" DBAs I've ever worked with has been absolutely useless (unless they're actually a dev wearing a DBA hat). If the rule is that that sort of shit "has" to be done by a DBA, get the rule changed.

    I think your obvious solution's underpowered.  This is the 21st century, after all.  <snip /> tl;dp


Log in to reply