Re: word games (was: TDD & tests & mocks)

Hi Sam,

When I suggested asking them "How do you do your testing" I was figuring
you might get a range of answers, like...

"We give the finished code to the testers."
"We try to write unit tests but we don't always have time."
"We're learning TDD but not that good at it yet."
"We do TDD for 70% of our code."
etc.

Some of those answers would send me away.

In my experience, high risk domains tend to do less programmer testing and
more after-the-fact functional testing by QC people. I don't think it
should be that  way but it's what I've seen.

Regarding the interview and being "choosy" I guess to be choosy, you have
to get to a point where you have choices. To me, that means skills.

Charlie


2016-08-25 15:41 GMT-07:00 'Sam .' [email protected] [extremeprogramming] <
[email protected]>:

>
>
> Hello,
>
> During the past days, several words from this email kept ringing in my
> head, so I returned.
>
> @Charlie
> > * How do you do your testing?
>
> From what I have experienced and learned, there are companies / IT domains
> where quality is critical, others where "relatively" would do. Therefore,
> in ordinary GUI applications, games, probably getting to the market quickly
> is more important than coming with a very stable product. In automotive (I
> suspect, also medical) domain, the company cannot allow slipping bugs that
> would kill a man. Though I doubt big corporations, with a complicated
> process and procedures for every possible thing could be fun or anything
> agile, for that matter.
>
> How would you relate agile methodologies with IT domains? Do you think
> some domains tend to be less quality-oriented, or less agile than others?
>
> >  Of course, this approach may not work for everyone. You have to be
> willing and able to pass up things that are almost good enough for you.
>
> The social environment is also a tricky one to figure at any interview.
> Problems can range from respect not being a value upheld by the firm, to
> Command & Control management, to dysfunctional teams that are regarded as
> normality, to strange mentalities.
>
> Looking back at my past jobs I notice social issues & mentalities that I
> had found discouraging, but I doubt I could have figured them out at the
> interview.
>
> What questions do you ask to figure such things out?
>
>
> > My observation is that many good developers are insufficiently choosy
> about where they work.
>
> There are probably several issues they face, I think:
> 1. Poorly skills at interviews usually means you can get to a job not
> better, perhaps even worse, than the one you had before.
> 2. Leaving one job after another makes you a job hopper, which decreases
> your chances at future jobs.
> 3. You can get discouraged by the fact that "Everywhere else is like this"
> or "In other places it's not better either."
>
> So it may all come down to the interview.
>
> Sam
>
>
>
>
>
> On Monday, October 12, 2015 12:55 AM, "Charlie Poole
> [email protected] [extremeprogramming]" <extremeprogramming@
> yahoogroups.com> wrote:
>
>
>
> XP is quite specific. For that matter, so is FDD, and many other
> methodologies. If someone says they are doing a very particular
> methodology, it's likely they are at least trying to do it.
>
> If they simply say they are "agile" or "doing Agile" that's another
> matter. Agile is a category, not a methodology. Almost anything can be
> called agile, and almost anything has!
>
> The fact that many people have never heard of XP is - of course - one
> reason why they aren't faking it. If XP were a big, widely-twittered,
> buzzword with lots of marketing behind it, then people would pretend to do
> XP. As it is, they don't... for the same reasons that bank robbers don't
> try to break into my grandchild's piggy bank: there's nothing to be gained
> by it.
>
> As far as ascertaining how well folks are doing XP - or even whether they
> are really doing it - it's a no-brainer for anyone with XP background to
> ask the right questions:
>
> * How do you do your testing?
> * Do you actually have an on-site customer?
> * What things do you pair on?
>
> * ... and so on
>
> Of course, this approach may not work for everyone. You have to be willing
> and able to pass up things that are almost good enough for you. My
> observation is that many good developers are insufficiently choosy about
> where they work.
>
> Charlie
>
> On Sun, Oct 11, 2015 at 2:24 PM, Sam [email protected]
> [extremeprogramming] <[email protected]> wrote:
>
>
> On Jo, 2015-10-08 at 16:54 -0700, Charlie Poole [email protected]
> [extremeprogramming] wrote:
>
> > If you see a company that says it does XP, give them a shot. It's
> > harder to fake and there's no motivation to do so.
>
> Or perhaps few have heard of XP, and those who had have no idea what's
> with it. Taking a look on wikipedia about agile development, I see:
> (agile methods)
>
> Adaptive software development (ASD)
> Agile modeling
> Agile Unified Process (AUP)
> Business analyst designer method (BADM)
> Crystal Clear Methods
> Disciplined agile delivery
> Dynamic systems development method (DSDM)
> Extreme programming (XP)
> Feature-driven development (FDD)
> Lean software development
> Kanban (development)
> Scrum
> Scrumban
>
> Many of them I haven't heard in my life. Possibly other people find XP
> as just another practice in a list.
>
> What do you mean by saying "it's harder to fake"? And how would you
> define XP in a few words, in such a way that one could check by that
> definition whether a firm does or does not XP?
>
> Sam
>
>
>
>
> 
>