|
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.
|
|
|
|
|
Bollocks. Collaboration is a waste of time. It usually devolves to extended meetings discussing the best color for a specific button.
".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
|
|
|
|
|
I believe Agile is a pipe dream. In theory, it's the best, but in practice it falls far short. I attribute this disconnect, at it's origins, to a complete bastardization of the paper that started it all, The New New Product Development Game (Harvard Press, 1984), which doesn't mention scrum (a rugby term) but does mention rugby. They basically said that new innovations to existing products could be produced faster/better if 1) a small interdisciplinary team worked together, 2) management gave them goals and then got out of the way, and 3) the team was free to take risks. What we got was Agile/Scrum, which is basically a management control layer used for new and existing products where risks are avoided. Completely not the same thing.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Over the years, I've worked on numerous projects with various project management methodology. Each has its own strengths and weaknesses, and each has a situation where it should never be used. I won't restate the obvious.
Agile is an ideal project management method where you might have a stakeholder or manager that has severe ADD and is always chasing rabbits. The rabbits become the project. Feature creep that is deadly in other management methods can be embraced with Agile, usually with good results. If somebody is paying for the development, then why complain? You will tend to create a product that is more what the customer wants (admittedly guided by a subset of end users).
If you have a product that is continuously being tested by users, the feedback that you get might be quality input and provide direction for the order ("sequence") that you implement certain tasks and how to create or adjust certain UI features. If you get an informed set of test users, you might get ideas for implementing useful sub-features or workflows that might not have been conceived at the product design stage.
With Agile, you tend to have a releasable product sooner and with better end user acceptance.
With Agile, management and stakeholders have a more visible window into progress of the project/product. Showing continuous visible progress can have a good job security angle.
Agile can be useful when writing a software product used by many people. UI, Web page, tax software, spreadsheet, word processing, technical calculation app, scenario handling, ...
Agile should not be used if the objectives are very clear, or deviation is a failure. It should not be used for software projects launching a rocket, calculating orbital mechanics, security tokens, SSL/TLS, financial transactions.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
You mean that I am personally responsible for that many people failing courses, and not joining the workforce as developers?
Do I get a medal? 
"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 I get a medal?
Are 2.6M (and rising) rep points not enough for you?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: Are 2.6M (and rising) rep points not enough for you?
Of which, between 94.6% and 98.3% are using that boilerplate post.
Brilliant - P.T. Barnum would be proud - it's never a bad idea to go for the low hanging fruit, first. Unfortunately for my, due to time zones, I don't get in on this until most of these have been answered.
I'm not bitter. I though about it and am not even vengeful. Perhaps awestruck or starstruck?
| 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 |
|
|
|
|
|
No, but you have become part of the process of weeding out the duds.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
H G Wells: War of the Worlds (opening lines)
No one would have believed, in the last years of the nineteenth century, that human affairs were being watched keenly and closely by intelligences greater than man's and yet as mortal as his own; that as men busied themselves about their affairs they were scrutinized and studied, perhaps as narrowly as a man with a microscope might scrutinize the transient creatures that swarm and multiply in a drop of water.
Code Project:
No one would have believed, in the first years of the twenty first century, that Q&A questions were being watched keenly and closely by intelligences greater than man's and yet as mortal as his own; that as men busied themselves about their affairs they were scrutinized and studied, perhaps as narrowly as a man with a microscope might scrutinize the transient creatures that swarm and multiply in a drop of water.
|
|
|
|
|
Personally, I saw that post and agreed with you. It is not being harsh to point out reality. I have been a programmer for just under thirty years, but have watched better suited people rocket past me.
|
|
|
|
|
You underestimate the power of AI.
Answer: "Ask Siri, she knows"
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
I won't have one of those shameless hussies in my home!
At the very least, I have a wife - one female voiced entity awaiting an opportunity to pounce is all I can handle
| 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 |
|
|
|
|
|
I got you, 3 to 1. I have 2 daughters. No, make it 4 to 1. Almost forgot the granddaughter.
Genius: The guy who put the mute button on hearing aids.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Here we see again how important artificial intelligence can be to the naturally dumb.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
W∴ Balboos, GHB wrote: Well - the only ones left will be the current Q&A Posters.
That's a scary thought. 
|
|
|
|
|
That is so funny I nearly wet myself.
|
|
|
|
|
Not quite off topic - a few time in the past I posted "LSHIWM" and similar takeoffs on that horrid "LOL" - so clearly your mental facilities are careening towards a crash in the right direction.
| 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 |
|
|
|
|
|
Quote: A programmer braindamaged by years of programming Intel processors wants to have the instructions PUSH/POP also for the 68000. He solves the 'problem' in the following way:
I agree, Intel processors cause brain damage. I would even extend that to all CISC processors.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Push and Pop were always two of my favorites. Even had a POP manual: (370) Principles of Operation.
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
|
|
|
|
|
In my case it's more about the little differences between RISC and CISC processors. I have a nice set of general purpose registers, of which any can be made the current stack pointer at any time. While this is a cross assembler, it still generally assumes a CISC processor. I have two stacks, a parameter stack and a call stack. For all calls it must be sorted out, where the parameters come from (other registers or rarely memory) and what stack they need to go to.
The coolest thing is that the processor does the same trick with the program counter. This opens up a neat possibility. It's a typical 8 bit processor which can only address up to 64k. Of course you can add a larger banked memory, but doing the bank switching in code will get complicated and error prone.
By having multiple program counters, I can move the bank switching into the calling protocol. I can call any routine in any part of the banked memory without any complication.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: I have a nice set of general purpose registers, of which any can be made the current stack pointer at any time.
You could go a lot further. What was the name of that TI chip (9900?) that had all its registers in RAM, with only a single "register block pointer" in the CPU? So general performance was mediocre, but interrupt response was excellent! A single clock cycle to set the register block pointer, and the interrupt handler could start using its private registers, with no need to save anything at all. Same for processes/threads: They all had their private register sets.
A less extreme variant: One of the first CPUs I programmed had 16 register blocks (each consisting of 16 special purpose registers), one block for each of the 16 interrupt priority levels. When an interrupt signal arrived, the first instruction of the handler was executing 900 ns later, which was quite hefty for a "PDP-11 class" 16 bit mini in the mid 1970s. But this was limited to interrupt handling: All ordinary user processes shared a single register block.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
