The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen. For those discussions where you wish to be a little more frank, use the Soapbox[^]
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Fetch = tokenFoo
Fetch = tokenBar
Fetch = tokenBaz
// parser recognizes those three in a row so it reduces to a rule
Foobar -> tokenFoo tokenBar tokenBaz
You don't get the rule to reduce to until after the tokens are read. You have no idea how many tokens it takes to resolve a rule until after the fact. Which is fine. Usually.
So to build a tree, you have to keep a stack, push any tokens fetched, and then whenever you reduce to a rule, you pop the tokens on the right hand side of the rule, and push a new token for the left hand side of the rule. Easy.
The trouble is when an error is encountered. You won't necessarily get the right number of tokens back
(the parser can actually handle this part, but the tree builder can't)
Fetch = tokenFoo
Fetch = error
Reduce = FooBar -> tokenFoo error ???
Ouch. I don't have enough tokens.
The trouble is, I don't know I don't have enough tokens until the stack is empty.
So basically, I can't even build trees from a shift reduce/LR parser if there are errors in the input.
This is BAD.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another.
Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since this was originally written (1982 or so).
If the chicken has already crossed the road, then you no longer have to implement Agile.
No, no, no - that's not how Agile™ works. The chicken stops every six inches while it walks across the road (these are 'sprints'). It verifies with the stakeholder (aka the farmer) at each point that he's getting what he wants, i.e. the chicken across the road. The farmer can adjust the chicken's route any time he likes.
Of course, none of the principals notice the traffic on the road...
Yeah, you are correct that the original Mythical Man Month was written in 1975 but I wasn't sure if this was part of the original or the revision (1982) so I guessed the latter so I woudln't make it sound too old.
If one of those women was already eight months pregnant, and those chances increase if you (randomly) take more women.
Or have them steal a baby, at least one out of nine should be successful!
If I wanted a baby, and I wanted it as fast as possible, I'd take as many women as I could get and not take any chances
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Last Visit: 20-Aug-19 12:50 Last Update: 20-Aug-19 12:50