| Newsgroups |
gmane.comp.programming.extreme-programming |
| Message-ID |
<[email protected]> |
I’m finding the bigger problem to be massive amounts of legacy code, combined with aggressive delivery schedules that make retraining and mentoring a challenge, and managers who simply don’t get the value of unit tests. In at least one case, a senior director was too afraid of developers leaving to prod them to start unit testing.
It’s even more challenging when the company needs to maintain older versions of the code.
Progress is sloooow
> On Aug 25, 2016, at 7:21 PM, Charlie Poole [email protected] [extremeprogramming] <[email protected]> wrote:
>
>
>
> 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] <mailto:[email protected]> [extremeprogramming] <[email protected] <mailto:[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] <mailto:[email protected]> [extremeprogramming]" <[email protected] <mailto:[email protected]>> 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] <mailto:[email protected]> [extremeprogramming] <[email protected] <mailto:[email protected]>> wrote:
>
> On Jo, 2015-10-08 at 16:54 -0700, Charlie Poole [email protected] <mailto:[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
>
>
>
>
>
>
>
>
>