|
I hunted high and low for the full version of "Space Quest X: Latex Babes of Estros", but no ... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Then you must live with 'Space Quest 6: The Spinal Frontier' 
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.
|
|
|
|
|
|
How about SQ3?
Roger eventually discovers the sinister activities of a video game company known as ScumSoft, run by the "Pirates of Pestulon".
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.
|
|
|
|
|
Charming!! What have I done to offend you?
|
|
|
|
|
C'mon, the report engine to which you refer isn't that bad!  What report engine would you prefer to work with?
"Go forth into the source" - Neal Morse
|
|
|
|
|
In such cases I am asking for a raise and some benefits like a new PC and snacks. 
Maybe it is time to take some drugs to get ready for this dirty job.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Agile software development[^]
I'm currently in a situation where I constantly run into changing requirements, "misunderstandings" (=other name for changing requirements, but I get the blame), dependencies on moving targets, ...
When I challenged the person in charge (for the lack of design) I got: Yes, but you don't know, and have no experience in, the methodology we're using here. Personally I believe agile is a methodology invented by managers who failed to understand the importance of design and documentation. Furthermore, I'm pretty sure this person has no clue about any methodology, bu rather "goes with the flow".
Though I see a benefit in using this when doing prototyping and/or proof of concepts, I fail to see any value when doing real (operational) products which could (and should) be defined.
Opinions?
|
|
|
|
|
Even if some managers think so, agile does not mean that there is no planning and everything is done whenever someone feels like it.
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.
|
|
|
|
|
please, come explain that here 
|
|
|
|
|
10 months ago I left a company where they also thought that Jedi handwaving was very agile. I just got out and did not waste my time explaining anything. 
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.
|
|
|
|
|
V. wrote: Yes, but you don't know, and have no experience in, the methodology we're using here.
Then it is up to him to explain the process to you - and you should be able to challenge every assumption, logical fallacy, incorrect belief that he comes out with. If the process is so strong, he should have no problem with you questioning it.
This space for rent
|
|
|
|
|
true, so he blames in the client. Which is partially true, but personally I would have told the client what they needed to do first before we started anything... 
|
|
|
|
|
This is something I hear often. It's the idea that agile means you can skip the requirements gathering phase altogether. That is not, and never has been, the case. You still need a rough idea of what you're going to build. And it's your responsibility to work, with a representative of the client, to determine at the start of each sprint, what you are going to deliver. That means that they have to have provided enough detail going into the meeting to work out the rough shape and size of each task.
This space for rent
|
|
|
|
|
Even more: Get everything out of the way you can. Your team has to know enough of the architecture and the technologies used so that you can assign them tasks that tell them what needs to be done, not how to do it.
In sprint planning I want to define tasks like this:
We need a new entity named <whatever> that has the following properties: (list), possibly some reference to the requirement documents.
Also, we need a data access object with data access methods to cover the following requirements: (another list of references to the requirements and possibly some elaborations)
No need to lose a word about how to do that, where to place these objects or what technologies to use. My boys know that before writing the first line of code and there probably will be more assignments like this coming their way.
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.
|
|
|
|
|
That is absolutely horrifying.
|
|
|
|
|
Actually, and with mixed but increasing success, I try to explain to the client* what they need and how they need it. They're a clue-less lot and if I didn't (or they just don't want to listen) then the effect is much more like what you've experienced.
Interestingly, word of mouth (?) has it that IT knows what it's talking about when it comes to IT. Imagine that!
* Client as in defining users as these are in-house users.
| 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 |
|
|
|
|
|
unfortunately I'm not asked to talk to the client...
Although in this case, I might not want to, either.
|
|
|
|
|
If you can't talk to the client you are toast.
|
|
|
|
|
Agile Software Development: sorry, but that's an oxymoron.
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
Not really. If
- there is a well defined architecture
- there is a detailed documentation of the requirements
- every member of the team is familiar with this architecture and the platform
- a realistic sprint planning, producing a list of managable tasks
it can work. By taking architecture and the target platform out of the picture as a prerequisite, you can concentrate on the work at hand.
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.
|
|
|
|
|
And that's my point, 2 choices to make agile methodologies work:
1. as you've done simplify the target / break it up
.... (even seen attempts to waterfall ahead of the project plan)
2. (like RyanDev - next reply) take 'parts of' the methodologies
.... so it's not really agile or scrum, it's a hodgepodge of what sounds good
3. most commonly combinations of 1 and 2
.... so true to the definition it's not agile, it's ad-hoc pm.
But in fairness, to 100% perform properly to many tasks become impossible, slippage is almost not allowed and even small failure definitely not handled properly without throwing out the entire plan for the workaround, lack of flexibility, just unreasonable to ever perform 100% purein the real world. (Achieving real word pure agile ranks alongside the traveling salesman / 4 colors puzzles.)
Sin tack ear lol
Pressing the "Any" key may be continuate
|
|
|
|
|
CDP1802 wrote: By taking architecture and the target platform out of the picture as a prerequisite, you can concentrate on the work at hand.The language is JavaScript. that of Mordor, which I will not utter here
It's like that almost all the time - before agile.
Braking project up into bit-size pieces, making sure they all work, &etc. What's really so novel about that? Now creating a test before you've something to test - honestly, that's like taking a dump before you drop your pants. (i.e., you heart's in the right place - nothing else is.)
| 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 |
|
|
|
|
|
Most people don't know the difference between strategy and tactics.
Strategy is when many bigwigs stand around a plan and take a look at the big picture. Tactics are when the little soldiers are actually fighting in the trenches and must react to constantly changing situations and see only a small part of the picture.
You are in trouble when you treat one like the other. Treat architecture and the 'how tos' strategically and take all the time you need to think them through and make your troops familiar with the plan. Have them out of the way when the actual work begins.
I see agile as a way to handle the implementation tactically and to help you to react quickly to unforseen situations or changes.
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.
|
|
|
|
|
The detailed documentation of the requirements is the most important point. How detailed, these are the specifications that your team will build to. Most helpful are the expected inputs and outputs, which you get from questioning the customer or the marketing dept. IPO mapping is best for this, then the internal processes and objects. From these, the team designs the architecture and user interfaces.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
