Language:
switch to room list switch to menu My folders
Go to page: [1] 2 3 4 5 ... Last
↑↑↑ Old messages ↑↑↑            ↓↓↓ New messages ↓↓↓
[#] Tue Sep 24 2013 12:02:38 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


Arrgh.

I want to get all of the people who are demanding my undivided attention today on a big conference call so they can fight over me while I go somewhere else to be productive.

[#] Thu Sep 26 2013 12:47:00 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


My "urge to go postal" is directly proportional to the volume of loud, only-half-workplace-related ad-hoc conversation right next to my unshielded desk. Get a room, people! #MogSmash #WhereIsMogAnyway

[#] Thu Sep 26 2013 12:48:00 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

I want to get all of the people who are demanding my undivided
attention today on a big conference call so they can fight over me
while I go somewhere else to be productive.


Only if none of them have an accent. "If you have an accent, you shouldn't be on a conference call." --name withheld.

[#] Thu Sep 26 2013 17:52:51 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

That's actually a bit of a real problem. Some people have thick accents that make their communication almost completely unintelligible. For positions requiring a great deal of communication with customers this disqualifies them.
Someone with enough butthurt could easily mistake this for racism.

[#] Thu Sep 26 2013 18:50:25 EDT from zooer

[Reply] [ReplyQuoted] [Headers] [Print]

The only problem is the NY city accent. And I don't care which boroughs, neighborhood or county you are from.

[#] Thu Sep 26 2013 21:45:33 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Combine "accent" with "soft spoken" and it's a recipe for disaster. One of our devs is unintelligible via phone when we do our morning meeting. If I'm in remotely I can't understand a word. It's just a bit better when I'm in the office for that meeting. This person becomes easier to understand when spoken to one-on-one, strangely.

[#] Sat Sep 28 2013 10:10:09 EDT from anonymous

[Reply] [ReplyQuoted] [Headers] [Print]

Dere's no such ding as a joisey accent or a NY accent.
Goddit?
So jus fuggedaboudit.
Ya joiks.

[#] Sun Sep 29 2013 18:03:31 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


So, at a time when a lot of people with my skills seek work, but know that many of the jobs we held were shipped overseas, it's kind of offensive to take a phone call from someone offering me a job while maintaining an Indian or Pakistani accent. Especially when you cannot understand the person well, because the accent is too thick.

It really makes you want to firebomb businesses.

[#] Mon Sep 30 2013 13:25:42 EDT from Ladyhawke

[Reply] [ReplyQuoted] [Headers] [Print]

I hear that, Fleeb.  Not bad enough they're outsourcing the jobs....now they're outsourcing the recruiters, too.  Though I suppose if they're going to seek the majority of their workforce elsewhere, it does kind of make sense, however odious.



[#] Mon Sep 30 2013 13:28:07 EDT from Ladyhawke

[Reply] [ReplyQuoted] [Headers] [Print]

This is how my last call went.

http://www.youtube.com/watch?v=zbJAJEtNUX0

 

On a completely unrelated note:  Left a request for assist (on behalf of a friend) regarding a sysadmin issue in the MicroBashing room, if anyone's got a moment.



[#] Mon Sep 30 2013 18:58:35 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


So... I'm hearing about current trends in software development, and it kinda makes me want to get out of the business altogether if it's true.

'Agile' development is this spiffy buzzword. I've heard of it... it's been around for several years now (maybe 10?), but I've never worked in a place that formalized the use of it.

But it's the rage... in perhaps all sense of the term. People seem to not quite understand the point of it, and use it to justify a broken management style du jour.

That is, they insist on doing non-stop sprints (which I take to mean 'rush to a target date') on a regular basis, rather than carefully planning out how long a given project will take, attempting to meet that, and only sprinting when they misestimate the time and need to hit their target date.

Basically, if I understand everything correctly, the same old techniques for managing software haven't really changed in the 15+ years I've been at it, they've just been codified into a bunch of terms for stoopid managers who have never actually worked on a development project to wrap their minds around.

Except they're stoopid, and they can't properly wrap their mind around it, so they bastardize the terms to their own broken ideals and push it off as 'Agile development', then get shocked when it doesn't quite work up to the hype.

Is this the norm now?

If so, the only difference between my past and now is that they have a bunch of new words to describe how poorly their managing everything instead of actually learning how to do the job right.

[#] Mon Sep 30 2013 20:55:49 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

But it's the rage... in perhaps all sense of the term. People seem to

not quite understand the point of it, and use it to justify a broken
management style du jour.

That's about the size of it. The only teams that really effectively implement agile practices are some of the tiniest, 5-dev teams... if you've got a team of 20 and you're pretending to be agile, you're not, you're just pretending

[#] Mon Sep 30 2013 21:08:17 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

That is, they insist on doing non-stop sprints (which I take to mean

'rush to a target date') on a regular basis, rather than carefully
planning out how long a given project will take, attempting to meet

that, and only sprinting when they misestimate the time and need to hit

their target date.

I think you're misunderstanding things here.

Agile is:

* implement small discrete chunks of functionality, incrementally. A week's worth of work seems about right. Plan, but don't over-plan.
* "sprint" is just an agile buzzword. It doesn't means "sprint until your lungs ache" or "work 60 hour weeks" or anything like that.
* automate everything you can, especially, as much of the testing as possible. At the end of each sprint, you need to be able to {release,deploy to production} with confidence, and absent a large sluggish QA team that will only slow you down, the only way to achieve some semblance of confidence is to automate what you figure out how, and then automate some more.
* Don't branch. Never box yourself into a months-long release cycle with diverging branches. Branch-in-code by using component architectures and "dark" code that is only turned on by configuration when it's ready to go.
* For startup teams that have not yet succumbed to bureaucracy and maintenance suffocation, and have a high tolerance for creative destruction

Agile is not:

* A buzzword-compliance fig-leaf for overly-large, legacy product teams where nobody knows what anybody else is doing, so that the management can feel better about their management style if they attend the right conferences drop the right newspeak and wear the right fig-leaf.

* For bureaucratic teams or middle managers who live in a culture of imposed bureaucracy. If those people think they're agile, they're just kidding themselves.

[#] Tue Oct 01 2013 08:15:42 EDT from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mon Sep 30 2013 21:08:17 EDTfrom LoanShark @ Uncensored
That is, they insist on doing non-stop sprints (which I take to mean

'rush to a target date') on a regular basis, rather than carefully
planning out how long a given project will take, attempting to meet

that, and only sprinting when they misestimate the time and need to hit

their target date.

I think you're misunderstanding things here.

Agile is:

* implement small discrete chunks of functionality, incrementally. A week's worth of work seems about right. Plan, but don't over-plan.
* "sprint" is just an agile buzzword. It doesn't means "sprint until your lungs ache" or "work 60 hour weeks" or anything like that.
 
a sprint is meant to be the pace of your team, in witch a set of tasks ("User Stories") can be finished implementing.
You should start with the complicated user stories first, so if you fail, you will fail early.
Knowing the Pace of your team (once its calibrated for some sprints), you should be able to estimate in how many sprints you'll be able to reach the goal; In principle you should have something "deliverable" after each sprint.

* automate everything you can, especially, as much of the testing as possible. At the end of each sprint, you need to be able to {release,deploy to production} with confidence, and absent a large sluggish QA team that will only slow you down, the only way to achieve some semblance of confidence is to automate what you figure out how, and then automate some more.
 
"contineuos integration" to name the buzword herefore. have a jenkins or buildbot or whatever, make it compile & autotest stuff.

* Don't branch. Never box yourself into a months-long release cycle with diverging branches. Branch-in-code by using component architectures and "dark" code that is only turned on by configuration when it's ready to go.
 
oh, didn't hear that one yet.

* For startup teams that have not yet succumbed to bureaucracy and maintenance suffocation, and have a high tolerance for creative destruction

Agile is not:

* A buzzword-compliance fig-leaf for overly-large, legacy product teams where nobody knows what anybody else is doing, so that the management can feel better about their management style if they attend the right conferences drop the right newspeak and wear the right fig-leaf.

* For bureaucratic teams or middle managers who live in a culture of imposed bureaucracy. If those people think they're agile, they're just kidding themselves.
 

Scrum seems to be a methodology to get everyone going...; one should have burn up/down graphs to estimate how many stories are finished, and revalidated by the "product owner" to be in the desired shape.

So far over here we've got problems in modifying the legacy code, which was evaluated by manual qa agents with point & click recipies up to now. They called that "breaking the Silos" - QA guys are distributed into the project teams now.

 



[#] Tue Oct 01 2013 09:02:17 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Huh... so based on what I'm reading here, people have different ideas of the meaning of the term 'sprint', as I've heard someone else describe it as a sort of 'rush to meet the deadline'.

So a sprint is intended to involve as much work as is required to accomplish about a week's worth of work. But if someone elects to give you more than a week's worth of work, it breaks the model, and you wind up in the hampster wheel, which seems to be how at least some people abuse it.

(As in, everyone knows the effort would require six weeks, but you're only given two weeks to do it, so you fail... repeatedly... until you finally make it, killing any sense of what a sprint should do for you).

[#] Tue Oct 01 2013 09:04:27 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I agree with tiny 5-man teams, though. Much more than that, and you have a communications nightmare. If you have a team of 20 people, you should break them down into four teams of five people each, and portion out the work across the four teams. Although I didn't need 'agile' to tell me that... you get that from The Mythical Man Month.

Hmm.

[#] Tue Oct 01 2013 09:16:49 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I also agree with automating what you can... to include tests.

I write a lot of test code already, although I don't do a good job of having those tests generate a pass/fail condition when executed (although I know I should). But if I did, and if I had a proper build system that generated everything, I could test that any new code didn't break old code without having to do a QA cycle, just by running the tests as part of the build cycle.

Your QA team ought to just test new features and regression anything that cannot be automated for some reason. Otherwise, you're just not using computers to their fullest extent to help you.

[#] Tue Oct 01 2013 09:21:00 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Yeah, I hate branching as well. I avoid it like the plague.

But then, if you have a need to branch something, you probably have a design flaw. A component design flaw, rather than an object design flaw.

That is, you probably have some gawd-awful huge executable that is intended to do everything, instead of a system of executables that work together to accomplish a common goal. Or, at least, something like that.

I try to design systems to do one thing, and one thing only. I try to resist designs that force a system to do more than that one thing. This comes back to a unix design philosophy that I have found works extremely well in large scale projects. But it also helps avoid branching code... it's easier to create a feature that you can turn on through a configuration item somehow when everything is very modular like this.

[#] Tue Oct 01 2013 09:24:16 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


"A high tolerance for creative destruction," sounds like a very nice way of saying that developers should learn not to be so wedded to their own ideas that they can't listen to someone else and critically work through whether that idea is better or not.

Especially if that idea is an old idea that you collectively have been working towards for some time... if a better one comes along, you should at least consider how one might implement it given your current direction.

This is a tough one, I think. Developers can have such huge egos sometimes. You have this thing you've been working on for a while. You've thought it through, and you've built a lot of scaffolding to implement it, when something else comes along that would work better. It can be hard to admit it sometimes, or even hard to see it if you're too close to your own work.

[#] Tue Oct 01 2013 16:12:52 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Your QA team ought to just test new features and regression anything

that cannot be automated for some reason. Otherwise, you're just not

using computers to their fullest extent to help you.

Bingo.

Unfortunately legacy QA teams tend not to get this, especially if they're involved in code review cycles for a critical project...

If they're involved in review, they're seeing the unit tests too.

Then they insist on replicating every unit test manually, and adding that to their repository of manual test cases that must be run forevermore on each release...

This can only lead to heartache. Never hire a QA team.

Go to page: [1] 2 3 4 5 ... Last