The Lounge - CodeProject

Try it now - I muffed the URL the first time.

TTFN - Kent

Fixed.

A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.

Forget it. Terra's enemies have nothing to laugh when we send them some of those.[^]

The language is JavaScript. that of Mordor, which I will not utter here

This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.

"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."

That reminds me R2D2 or dr.Who (the old one)

M.D.V.

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.

Ste-ri-lize imperfections!

The difficult we do right away...
...the impossible takes slightly longer.

Quote:

The robot, known as K5, ...

Only four generations away from an annoying robot dog. Roll eyes | :rolleyes:

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

More dildo than Dalek -- and it doesn't have legs for a pistol holster.

I wanna be a eunuchs developer! Pass me a bread knife!

I think I work in an environment teetering on the edge of toxicity.
Our shop follows "strict agile principles" says our leader to any outsiders unfortunate enough to ask about our processes and get a response. Previously we were a self-guided waterfall group which transformed from a ten million dollar company that was eventually bought by an enterprise.
Present day, we have added a few more heads; one of which is a "senior" who is baffled by things like string.Format, generics and well most any other concepts beyond Hello-world and IDE features, but he's got 20+ years experience... he didn't get fizz-buzzed or any coding interview btw.
But I digress. Now our process is "agile". And by "agile" I mean we subscribe to the following practices:
- Sprints vary from 1-6 weeks and are as predictable as the weather on Jupiter
- User Stories? I hear the term often, but the team has never actually seen one
- Estimation and Planning, we do this sporadically but it has been a while since the last one
- Tasks are added to the sprint EVERY day
- Need clarification/details on tasks like "Implement Security" and "Improve Performance", ask the product owner
- Have concerns about a feature or edict that would be construed as a bad practice or horrible UI layout, take it up with the product owner
- There is no official product owner and the tasks above typically come from the leaders or their suboordinates
- Retrospectives, i think we've had one of those.
- Backlog grooming, thats where you add more tasks right?
- Conversations like this happen often:
Mgmt: We need to implement feature Y for the release we scheduled 45 days from now (based on no estimates btw)
Dev: You told me feature X was priority. We spec'ed out feature X so we could deliver a finished product in 45 days. Which is a priority?
Mgmt: Both... (along with a WTF are you asking expression)
Dev: Lets assume feature Y takes the same time we think X will. Thats 90 days. You want that in 45 days?
Mgmt: Yes, you guys are sharp. You're a great, talented group; you'll figure it out (<- Leadership training)
Dev: Talent aside, time is time... where are we going to squeeze this extra stuff in?
Mgmt: Wherever you can. Theres always nights and weekends right?
- Theres a graph that tracks the burndown for tasks to the end of the sprint. Mgmt is concerned about why it always trends upward and never down. Perhaps its a bug in TFS. Solution: don't estimate something until you start working on it...

I could write a novel, but nonetheless. I once wondered what it was like to work on a dysfunctional team, but now I think I know.
It could always be worse right? Right?!!
</endRant>

Leave.

It's not going to get better.
And if you start regularly doing evenings and weekends to meet artificial and manipulated deadlines, they will start to expect it. And then rely on it - and finally insist on it. Elephant that!

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

Spot on! +24 billion points to you, good sir. Big Grin | :-D

Concur.

Exactly righ. It will never get better. Been there too many times...

Concur.

This.

That might be a great environment for some--some people get off on working themselves to a frazzle.

However from jeeves' rant, he's clearly not one of them. He needs to find something else to do.

I think one clear thing (from the way jeeves framed it) is that these truly are artificial deadlines.

Sure, there are occasions when, due to regulatory changes or something like that, a date truly is a must-not-miss, and we need to put in extra effort.

Because some sales drone told a (potential) client that "hey, this feature will be in our next release"? DFC. Sales drone needs to address what is clearly his problem then. (Or, we can consciously choose to reallocate resources or shift priorities, that's O.K. However, if everything is top priority, then nothing is).

jeeves77 wrote:
Theres always nights and weekends right?

Yes, but you ain't in it Cool | :cool:

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

jeeves77 wrote:
I once wondered what it was like to work on a dysfunctional team, but now I think I know.

This is a perfect opportunity for you to get things going in the right direction.

No workplace is perfect and people that leave a job just because there are issues are never happy because every workplace has issues.

Study up on Agile and SCRUM. These principles can work very well for certain teams. Then start suggesting improvements. If no one is willing to listen then perhaps it's time to start looking elsewhere. But imagine the job satisfaction you'll have if you can make a big impact on the process.

There are only 10 types of people in the world, those who understand binary and those who don't.

RyanDev wrote:
These principles can work very well for certain teams.

A myth often heard, and rarely seen.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Eddy Vluggen wrote:
A myth often heard, and rarely seen.

As one who lived it, I can tell you it is possible. Sniff | :^)

I think the problem is people try to follow it religiously and the truth is you need to make small adaptations to work with your environment. Trying to follow it exactly as is will likely not work.

There are only 10 types of people in the world, those who understand binary and those who don't.

It's possible, but then you were at a place where a majority of the developers and 100% of the management was competent.
But guess what, under those circumstances most methods would have worked.

Wrong is evil and must be defeated. - Jeff Ello
Any organization is like a tree full of monkeys. The monkeys on top look down and see a tree full of smiling faces. The monkeys on the bottom look up and see nothing but assholes.

"100% of the management was competent"

You're funny. I like you Wink | ;)

In my experience, the real problem is that management doesn't change, but they expect the team to be agile. A team cannot function in agile unless management also buys into it...

Things like: having a product owner, understanding that X points fit per sprint, tasks do not come into the sprint or carry over the sprint. The lack of a real backlog and user stories means management is failing. They cannot have any idea what a teams throughput is, compared to the expected work without both a prioritized backlog and a team velocity tracked over history. And thus, they cannot actually plan a release.

Anyway, I think most management see 'agile' as a silver bullet which allows them to change priorities regularly and still expect everything to get done. But its not, its a tool for tracking expectations... through team empowerment (which means managers have less power). Managers simply build teams. Scrum masters lead teams (and protect them from management). Business owners set priorities. The team is the central power.

If managers don't want to listen to their teams... then they can read about them in the exit interviews.

Pualee wrote:
A team cannot function in agile unless management also buys into it...

There are only 10 types of people in the world, those who understand binary and those who don't.

This is not about agile. This is about stupid.

Wrong is evil and must be defeated. - Jeff Ello
Any organization is like a tree full of monkeys. The monkeys on top look down and see a tree full of smiling faces. The monkeys on the bottom look up and see nothing but assholes.

Simon O'Riordan from UK wrote:
This is about stupid.

Deciding that based on the little information you have... D'Oh! | :doh:

There are only 10 types of people in the world, those who understand binary and those who don't.

Welcome to the Lounge