|
raddevus wrote: Many people (developers) have no real process.
We got processes.. lots and lots and lots of processes, all documented, all heavily enforced.. that's part of the problem 
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: lots of processes, all documented, all heavily enforced.. that's part of the problem
Yeah, it really is the problem. And at the root of that problem is:
Quote: the people who try to tell you what the process should be have never actually worked through the process themselves.
|
|
|
|
|
raddevus wrote: alas, it is described in so many places so poorly.
Of course it is!
That's because it demands that lowest priority be given to documentation!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: That's because it demands that lowest priority be given to documentation!
That's a funny catch-22!
|
|
|
|
|
It's a cop-out, really.
There's no good way of fitting documentation into agile, so they just sweep it under the carpet.
No technical writer worth his salt will document a function until it's been completed and signed off -- which only ever happens at the end of the sprint, so there's no time left for the guy to learn what it is/does and document it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Actually, it's explained as...
... The implementation is the documentation.
It's a "forRealz" statement because they know that 99% of the time people create documentation then code and never update the documentation anyways so the documents never represent the implementation anyways.
But, alas, 6 one way, half a dozen the other. People will argue both ways and that pays the consulting fees. 
|
|
|
|
|
W∴ Balboos wrote: Agile - an MBA's idea of how programming should be 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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
One of my pet peeves is with people who take apart something I have laboured over and perfected, only to completely mess it up. It happens so often that I just sit back and watch the fun these days.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
Brent Jenkins wrote: 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."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Ha.. back in the office this morning and there's an email asking if we're all available to work weekends through to January.. 
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
I remember a meeting with a boss and his underlings where he was told that they were selling their product too cheap and that they were losing money on each item sold. His response: "Then we must sell more. Underlings, make that your top priority!"
Sometimes I think that they don't put fools into a rubber cell with a tight jacket anymore. They just make them a manager somewhere.
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."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
It looks like its time to bail out of that company/project. It does not look like it will last 6 months.
|
|
|
|
|
It's due in February.. I'm trying my best to stay clear of it!
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
A few thoughts. You need to weaponize your knowledge.
1. Be aware of the difference between developer Agile and MBA Agile. It sounds like these folks are MBA style. Use that against them.
2. You say they dress and talk well. Throw out a few design pattern names. Hopefully they don't know them. That may cut them down to size and impresses management.
3. Make them fight among themselves. Tell one that their module must do this and talk to this other person's module thus. "You do not have a choice". Enforce that
4. Make a high level design and ask the/any programmer where their work fits into it.
.... Youngster....
|
|
|
|
|
Michael Breeden wrote: You need to weaponize your knowledge.
They're masters at this part of it all..
Had a meeting a few weeks back where I got a spiel about this process, that pattern, "re-hydrating entities".. basically re-loading the data from the database, but why say something in half a dozen understandable words when you can talk in paragraphs on a podium in front of clueless management?
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Well, you could perhaps go to the lowest possible level and just tell the truth. "We aren't getting anything done here". Really, could you ask what the "value" is or the "deliverable"? That is what Agile is all about.
Really, talking at a podium in front of management? That sounds too late in any case.
|
|
|
|
|
I'd like to buy you a beer.
Regards,
Rob Philpott.
|
|
|
|
|
and I'd like to drink that beer! 
|
|
|
|
|
R. Giskard Reventlov wrote: Simple: toss out agile and do it properly.
I was too chicken to post anything like that in public. (pssst, I think I was the tenth upvote on the comment)
R. Giskard Reventlov wrote: Oh, and fire all the script-kiddies and get some real coders in.
Disagree; totally.
Age is irrelevant. Yes, experience does count, but it's a matrix thing, not a linear one.
I'm Not sure of this at all, so ask a real lawyer or Human Resources pro, but I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members.
With that caveat, and reading your description, I highly suspect that your teams contain some members with very low verbal skills, and some members with very high verbal skills.
My sole opinion: That is the root cause of what you are describing.
Second factor: The Agile Approach. At times, I am convinced that the whole thing was intended to be a hoax, much like Administratium. (Go look it up if you've never seen the word before.)
Third factor: Money. You have used financial forces to induce, entice, and goad people into professing personal belief, adherence, and agreement with The Agile propaganda (^H^H^H^H^H^H^H^H^H^H development methodology).
Put those three factors together: [1] Disparate verbal skills, [2] The Agile Approach, [3] Financial forces; and I believe that what you are describing will happen in pretty much any project that requires software, firmware, electronics, website interaction, databases, whatever.
The self-contradicting paradoxes within The Agile Manifesto are so rampant and so wantonly linguistically absurd that I truly wonder how much alcohol is present in the bloodstreams of those people who make the decision to use it.
Turbo-charge these paradoxes with financial forces, then apply them to teams with no formal assessment of personal verbal skills among them, and, well, that's what you get !
My sole opinion. Anybody else who believes this has to pay me a dollar.
|
|
|
|
|
Interesting response!
C-P-User-3 wrote: With that caveat, and reading your description, I highly suspect that your teams contain some members with very low verbal skills, and some members with very high verbal skills.
I have no idea what this means in reference to my post. I am guessing you are taking the phrase script-kiddies and misinterpreting it. By script-kiddies I mean developers straight out of uni with little to no experience of the real world. All of the people in the team are articulate and smart (young or old).
C-P-User-3 wrote: I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members.
I have no idea if that's true or not. Regardless, you (or anyone) is not going to hire someone for a job that is incapable of communicating their ideas or displaying knowledge of development. That is the point of an interview.
Anyway, think you may have the wrong end of the stick here.
|
|
|
|
|
The real answer could/should be dogfooding[^].
Make the developers use the thing themselves.
It may be that the product / project is so overly boring that no one really uses it anyways so the devs descend into tweaking algorithms which are interesting to devs.
Somehow transform them into thinking about actually using the product and how important the final result it. This may work.
Edit
My point here is that the problem you are describing is that there is no "product owner" / visionary who is really driving things.
|
|
|
|
|
raddevus wrote: there is no "product owner" / visionary who is really driving things
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
