Welcome to the Lounge

The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.

1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.

The #1 rule is: Be respectful of others, of the site, and of the community as a whole.

2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.

4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions. Or if you must, use the Back Room[^] - but enter at your own risk.

5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen. For those discussions where you wish to be a little more frank, use the Soapbox[^]

6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.

7. Not everyone's first language is English. Be understanding.

Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.

We are a community for software developers. Leave the egos at the door.

Okay, one part for my supercharger project came in the mail yesterday. Not quite a flood, but, exciting nonetheless.

".45 ACP - because shooting twice is just silly" - JSOP, 2010-You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010-When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

Ignore me, I'm commiserating - Canada Post won't even put something as small as a CD in my mailbox and makes me drive a few miles to go pick up packages that would clearly fit in it (and that's my first world problem of the day)...

Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too..

The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months.

Personally, I think they're missing one major point mentioned in the Agile manifesto, in that..

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo).

On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it..

Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks..

Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.

It's too bad it has descended into that. I often talk about he _heart_ of Agile as it is defined by one of the two original "creators" of the Agile methodology in the following book:Scrum: The Art of Doing Twice the Work in Half the Time[^]It's really a great read and if you were to read it I believe you'd find, as I did, that Agile is a set of processes pulled together into a methodology that explains how real work is done.

Agreed.. some parts are useful, the bits that work are common sense.. the rest can easily be binned.

Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.

That was my recommendation, but that's off the table. These guys won't let go of Agile (I'm not against Agile, btw, but these guys are fanatics of [their interpretation of] Agile)..

I tend to concentrate on getting finished products out fast with as few bugs as possible (while accepting that it's impossible to avoid 100% of bugs). Unit testing gets added for complex functionality but ignored for standard run-of-the-mill stuff.. has anyone seen any articles promoting rapid application develop (but without 3rd party frameworks) over Agile?

I'm really looking for some evidence/white papers covering different ways of running the project - something that can possibly be enforced on the team, considering their poor performance so far..

One other issue, I'm an old-time coder (44 years old, started coding when I was 8), not a great people person.. (many of you may be surprised to hear that one! ) - these guys wear ties, have all the business spiel, great talkers and presenters.. makes it difficult to convince the guys higher up..

Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.

A slavish adherence to any process or set of rules will always end in disaster. What many people fail to see is that agile is a set of guidelines, not a be-all and end-all prescription for success.

I always try to hire people that are smarter than me (not hard, I have to say) and that have at least 10 years of experience and never have more script-kiddies than experienced people - the kids should be learning, not be the teachers (that isn't always the case, of course).The youngsters always want to use the latest, greatest thing. Without experience or guidance they really have no idea what they are doing.

By all means use agile, but adapt it to your team, not the other way around.

Agreed, but I also like the "latest and greatest" thing.. it's more about using it as intended and where it makes sense.. for example, I quite like Angular 2 - myself and another long term developer (from my team) created a working demo app for these guys. The Angular TS code was hand-crafted (very lightweight) with a simple ASP.NET web API back-end, and successfully integrated with a 3rd party system..

But these guys got their hands on it, deleted and refactored code, insisted on using Angular CLI which has led to them breaking pretty much everything, and they now need PowerShell scripts to be able to deploy anything to Azure (yes, really!).. it's a mess and doesn't work, but it's now sort of testable..

Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.

One other issue, I'm an old-time coder (44 years old, started coding when I was 8), not a great people person.. (many of you may be surprised to hear that one! ) - these guys wear ties, have all the business spiel, great talkers and presenters.. makes it difficult to convince the guys higher up..

Then let your bosses decide wether they want to believe their talk or their results - and then they must act accordingly.

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."

Yes, you are correct.. the devs are left to decide for themselves what is or isn't important. There have been (so far) no repercussions for failing to meet deadlines.

Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.

- does the sprint planning and prepares tasks- assigns the tasks- whacks them over the head when they complain about their tasks- whacks them over the head if they take too long- whacks them over the head when they mess with sometthing that's not their business- whacks them over the head if they have too many ideas- whacks them over the head for nothing once in a while, just to keep them on the edge

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."

Whomever is responsible for the 'team' or 'project' needs to define priorities and timelines.
If they are not being met, a determination needs to be made as to why and what the consequences are of not meeting the timelines: the project is not completed which results in lost revenue which can result is staff reduction for example.

If that person is you, address it with your management and ask what 'corrective' actions can be taken.