Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Re: The Evil Pleasures of Unit Tests

by pdcawley (Hermit)
on Aug 31, 2003 at 06:21 UTC ( #287986=note: print w/replies, xml ) Need Help??


in reply to Re: Re: The Evil Pleasures of Unit Tests
in thread The Evil Pleasures of Unit Tests

Why not find the 'guilty' party, pair with 'em, write the new failing test and then work with them to write the fix? That way you let them know you know that there's a problem, but you're also taking the pressure off them by solving the problem together.
  • Comment on Re: Re: Re: The Evil Pleasures of Unit Tests

Replies are listed 'Best First'.
Re: Re: Re: Re: The Evil Pleasures of Unit Tests
by dws (Chancellor) on Aug 31, 2003 at 08:54 UTC
    Why not find the 'guilty' party, pair with 'em, write the new failing test and then work with them to write the fix?

    That'd be the right thing to do if the team was collocated. Unfortunately, this is a distributed project.

      Did he say, "pull up a chair"? Electronic mail, instant messages, phone calls...

      You were gloating about it being an "evil pleasure" to play contract-lawyer and sue through the courts of team opinion, rather than settle your code disputes quietly with the affected party. It seems most of the replies indicate resistance to your interpersonal approach here. I wonder why?

      --
      [ e d @ h a l l e y . c c ]

        It seems most of the replies indicate resistance to your interpersonal approach here. I wonder why?

        There's a lot left out of the story, including meetings, agreements, phone calls, occassional pairing sessions, more meetings, more email, etc. Everyone on the team (well, all three of us) have agreed that good unit tests are essential, but in the heat of battle they get missed. The reaction so far as been "O.K., you caught me. I'll do better next time," which is pretty much what I'd hoped for.

      Oh hard luck. Please tell me at least some of the team is colocated.
        Oh hard luck. Please tell me at least some of the team is colocated.

        No such luck. We get together for a 3-4 hour whiteboard session once a week, and I get together with one of the other two folks once a week for a 3 hour pairing session. We meet up on irc on-demand. That's it. It's far from ideal, but it's the norm around here for teams that assemble ad hoc to tackle a contract.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://287986]
help
Chatterbox?
[davido]: yeah, umount -f isn't powerful enough.
[tye]: probably something in the init subsystem that does the mounting that you could disable and reboot.
davido needs to close laptop to board flight home from yapc.
[davido]: I'll look into it in a few hours probably.
[davido]: when i do get to that point I think I'll do it in a vm snapshot just in case. :)
[oiskuu]: tye, you were right: loginuid/sessionid are part of task struct if compiled with AUDITSYSCALL. I have some doubts if you should actually depend on that feature.
[Corion]: oiskuu: Depends on what you want to do with that information
[tye]: I'm not depending on that feature. But I could in this environment. I'm using getlogin(). shrug
[Corion]: For benign logging (which user started this DB instance), it's OK

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2017-06-23 20:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many monitors do you use while coding?















    Results (555 votes). Check out past polls.