|
raddevus wrote: THey just write code. Just writing code is terrible.
Just because they say so?
raddevus wrote: The book attempts to explain a process that a real person(s) can use to create a product, not just code.
Well - real programmers, by this definition, are simply not real people. I can go with that because real programmers are better than real people!
Apparently, by Agile standards, us real programmer earn our living by continuously doing the impossible. Mmmmmmm. Maybe.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: Just because they say so?
No, not just because Agile says so. I'm saying that code without a purpose isn't valuable to a company or a project. Developers often get stuck on code, but if the code isn't useful or usable the product suffers. Often, it is because developers are focused on other things like some beautiful algorithm.
I like software that works and that is really the true goal of a real Agile project.
Even this process that the OP has described isn't actually Agile, because they are missing a prime ingredient: product owner / visionary. Alas. 
|
|
|
|
|
raddevus wrote: Often, it is because developers are focused on other things like some beautiful algorithm.
Nothing gets a programmer's motor running quite like a really sexy algorithm. They can be quite distracting. 
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Foothill wrote: Nothing gets a programmer's motor running quite like a really sexy algorithm.
It's true. I too have fallen in love with my own code. 
Other people's code is boring though. Meh.
|
|
|
|
|
Narcissistic Programmer Disorder - a mental disorder in which a programmer has an inflated sense of their own code's importance, a deep need for admiration of their code and a lack of empathy for other programmer's code. But behind this mask of ultra-confidence lies a fragile self-esteem that's vulnerable to the slightest criticism.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
Reminds me of parents who love to take videos of their children, and when you go over to their place, those parents show (make you sit through) those videos until you are beyond numb.
|
|
|
|
|
The difficult we do immediately, the impossible takes a little longer. Miracles by appointment only.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
raddevus wrote: Many people (developers) have no real process. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups.
Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: I think that's nonsense.
There is a huge body of project failure stats that back it up.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
