|
You mean like this[^]
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Do alcoholics run in your family?
No they just stumble around and break stuff!
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
|
|
Yes, sadly I could not get any this year because of the lockdown, we are not permitted to travel to Belgium. So I just will have to do with some Dutch "Bock bier" 
|
|
|
|
|
Never did develop a taste for bourbon, I think it is a yank thing. The whisky on the other hand is delightful. maker's mark whisky at DuckDuckGo[^]
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Who will be doing the A's for the Q's ? Well - the only ones left will be the current Q&A Posters. That, of course, leads me to this simulation:
Question: Help me. I need to get my code done by this afternoon. I don't know where to start.
What I have tried: Help me. I need to get my code done by this afternoon. I don't know where to start.
Answer 1: I recall having the same homework question when I was a student. My solution was to post it at the CodeProject.com and ask for the answer, too.
Answer 2: I recall having the same homework question when I was a student. I never got a posted reply to do any of my homework all semester, except this guy, Original Griff, and he'd tell me to do my own homework. so I failed the course. Now I am contract manager for Agile projects
| 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 seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: Now I am contract manager for Agile projects
I don't believe: do you really dislike Agile? I am trying to convince you to like it.
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.
Which one of these beautiful Agile goodies looks like complete crap?
|
|
|
|
|
Agile - where the tail wags the dog.
And as a bit of insight, you know which end of the dog has the tail and what it's for.
| 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 seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: Agile - where the tail wags the dog.
I expected something like this... Looks like my advocating ability needs to be improved. Maybe I will try some time later. Meanwhile, I need to complete my sprint (scrum? sprint scrum? whatever).
|
|
|
|
|
The last environment I worked in where Agile was "practiced" had reduced it to worship. The only thing Agile represented was a dictatorship with a religion. The code coming out was worked and reworked until it matched the tech lead's code, whether it worked or not. Deadlines were blown and customers left waiting, but it was Agile.
|
|
|
|
|
The aims of aguile are laudable, though I'm not convinced that it produces good code in the long term - there is too much emphasis on short term goals and not enough on joined up thinking.
But as far as implementation goes, it's usually terrible: an excuse to get costs down by throwing code out the door without much if any quality control. Think about it: do car designers use Agile methods (outside the software component)? Do aircraft manufacturers (other than Boeing obviously)? Why not? Simple: their products have to pass actual independent testing to ensure they don't kill the customer ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Do car designers use Agile methods? Do aircraft manufacturers?
I wanted to answer here "Boeing, obviously", but fortunately, decided to read the whole reply.
|
|
|
|
|
Let me tell you the story of the agile bicycle. After the first sprint, minimal viable product was a frame, wheels and a set of handlebars. It could only go downhill. Fast - without brakes.
It was pretty dangerous until sprint five, where we put on a bicycle seat.
Lesson: Some things just don't lend themselves well to agile.
|
|
|
|
|
11917640 Member wrote: Which one of these beautiful Agile goodies looks like complete crap?
All of them?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Agile like all these 'processes' is great if people do it properly and stick to it throughout the project. But in my experience, after a few meetings everyone loses focus, or other pressures are put on people. The result is that they do "agile lite", which is as good as not doing it at all. I have never seen (in 40+ years) a project following any of these processes that actually delivered what it promised.
|
|
|
|
|
Agile like all these 'processes' is great if people do it properly and stick to it throughout the project.
sounds like class oriented programming.
I have never seen (in 40+ years) a project following any of these processes that actually delivered what it promised.
my experience is different. i have never seen (in 30+ years) any of these processes that actually delivered what it promised.
|
|
|
|
|
Never having used Agile--my salaried days predate it--I will make some observations.
Let's start with this. A process will not produce good software without skilled developers. But skilled developers will produce good software without a process, though a process can help them work more effectively.
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
Discovering requirements, yes. Developing solutions iteratively, yes. But those who don't write code have nothing to do with development except providing user feedback. And cross-functional activity must be managed, lest it significantly increase the number of lines of communication and totally busy people out responding to every twit who invokes their name.
It advocates adaptive planning, evolutionary development,
no different than any software process, because the nature of software is evolution
early delivery,
as long as everyone understands what alpha and beta releases are
and continual improvement, and it encourages flexible responses to change.
again, no different than any software process
|
|
|
|
|
Greg Utas wrote: as long as everyone understands what alpha and beta releases are
Microsoft do, though they use different names. "RTM" is "Alpha", "SP1" is "Beta", ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
They talk the talk, but don't know how to walk. Scraps for beggars (users); one scrap at a time.
An elephant is like a snake, except it isn't. But Agile says to focus on the snake; then the tree stump; etc. until you have not the elephant the user wanted.
Agile is like web development. One grotesque mismatched part after another.
One "trains" to be agile; you don't know Agile until you've done it; but it doesn't work "as described" out of the box. (i.e. no experience, you'll never get agile / Agile).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: One "trains" to be agile
Dogs are trained, people should be taught / educated.
|
|
|
|
|
11917640 Member wrote: Which one of these beautiful Agile goodies looks like complete crap?
The ones where managers say "we don't need a planning because we're doing agile!" and "we're going to adopt an agile approach, but we really need it done by [insert specific date]."
Another classic, switching priorities every other day because "we're agile".
Also a favorite, "we're doing agile so you're self-managing teams [I'll be out on the golf court]." 
|
|
|
|
|
"discovering requirements and developing solutions through the collaborative effort"; well yes, unless you're a lone worker (I am) then you're in a team, and this is what "team" means. Even if you're a lone worker, then you and the customer are a team - always have been, always will be. (Increasingly I'm my own customer!  )
"adaptive planning"; if project management doesn't adapt, it's not "planning", it was a plan. By definition, "planning" is ongoing and can therefore safely be understood to be adaptive.
"evolutionary development"; again, a tautology really. Unless you write a single line of code that completes the solution, it's an evolving solution.
"early delivery"; no sh*t, Sherlock. Which project management methodologies advocate late delivery?
"continual improvement". Well, I'm sure we have, as a species, always wanted to learn from our mistakes, and thereby continually improve. Right now, we're improving on "agile".
"flexible responses to change". Does "flexible" mean sometimes saying "no"? Hopefully...
I could apply the above description of Agile to any of the development paradigms I've had to work under in the past 40 years. They could all be summarised as "listen to the customer, help each other, and learn as you go".
|
|
|
|
|
Continual improvement in agile? That may be questionable. I have found, over time, that the codebase gets worse over time. That is due to the business pressure to get the software out. Then, later, when we need to add more features, we don't have time to adapt the similar part of the old code base to what the new feature demands (even when the calculations are the same) and the new feature is in another subproject. Either, it is easier and quicker to duplicate code, or use a cross dependency to the original code (with some minor changes to accommodate the new feature), then hopefully, later we will have time to fix up the bad code decision(s). Hence, technical debt. Then when we do want to fixup the code debt, it becomes difficult to convince the product owners and QA that retesting will be necessary and time will be needed to make sure that we didn't break something along the way.
I agree that it would be better to have allotted the time when adding in the new feature for correctly setting up the needed dependencies in the lower level projects, but management doesn't want to spend a lot of time testing (even regression testing) even for a new added feature. So, having the time to do a good engineering job is severely limited.
In other words, if we are not making revenue generating features (or fixing inhibiting defects), we are not encouraged to make the changes.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
