I've got one of those; easily the most convenient watch I've ever owned; battery recharges from sunlight, apparently. I say "apparently" because it's never been down to zero charge. The cost/time/efort in changing batteries once a decade is worth the extra expense of having a non-battery watch.
You know the reason that home PCs with humble specs can run the latest 3D games? Because they're also being developed for 10 year old consoles. Developers don't spend a lot of money in porting their 3D console games to the PC, hence the PC required for gaming has been relatively static for quite a while.
Now there are new more powerful consoles for people to develop games for.
Which, even if perfectly developed for, are still about a tenth as powerful as a gaming rig, and about half as powerful as the cheapest beige box there is. For the price of a new-gen console and 1 game, you would probably get a PC and perhaps 4 games of comparable performance.
Being anti-agile does not necessarily make one a lazy ill-disciplined developer. A dev could be anti-agile because... well, perhaps he resents being treated like a child,
If the dev considers collaborating well with others, taking ownership and responsibility of their own talents and shortcomings, being accountable to their team mates. If a dev considers such things to be akin to "treated like a child", perhaps the dev is still a child.
The fact is a lot of developers got into software because they could retreat into their own cave and not have to grow up. Not have to learn to work and play well with others.
Waterfall et al are all about micromanaging a schoolyard full of undisciplined developers. Agile is for adults, it requires a strong sense of personal responsibility that frankly a lot of devs just don't have.
--
The fact is Agile is the polar opposite of micromanaging. And that is why a lot of devs don't like, they can't stand the responsibility.
To be honest, in the twenty+ or so agile projects I've been on, it's only been the poor devs who like it. It allows them to spin wheels for weeks, knowing that any crap they write (magic numbers, strange assumptions about runtime, no error-handling, etc) will in all probability get thrown away anyway.
Re micromanaging: Devs who take full responsibility for what they do won't be micromanaged. Those who like CYA prefer it, as it gives them an out. THe sad fact remains that, in the decade or more since agile became popular, software failure rates have gone up, not down. No matter how vehemently you argue that it's better, the fact that it's correlated with failure still remains.
This thread is old, so I probably won't be replying again.
Dailies is a Scrum thing, don't mistake it for Agile.
Where in Scrum does it say 'wait until dailies to communicate'?
Where in my comment do I say "wait until dailies to communicate"? I asked "what's the point of dailies if you're already communicating?"
Honestly, the biggest problem with agile is dealing with the fundamentalists; much like creationists, they've got specific arguments that they've been rehearsing with the rest of the flock, like the kneejerk response I quoted above. The other similarity that agile has with jehovas witnesses and other nutcases is when you point to specific instances of it not working. Rather than concede that it doesn't work, they just shift the blame to the practitioner.
Ever consider that perhaps the smart folk avoid the agile folk simply because they don't want to talk religion?
And yet the reality is exactly the opposite: Agile methods are by strong people, for strong people.
That wasn't my experience of agile... at all!? The most memorable one was when I was part of a dev-team on a postgrad course. Team leader insisted on agile, and then insisted that the (relatively tiny) project be done only when we're all together in the same room (we lived about 60km apart from each other in a rough triangle). He then insisted that we meet and work on the project (tiny one for postgrad module) two hours a day every day after work, with sixteen hours each weekend over a two month period and insisted that no telecommuting would be allowed. I left the team (and halted my MS temporarily); last I heard they actually did stick to the proposed schedule but failed the course anyway.
My other experiences with agile development (bear in mind that I approached this as I approached most new things: "Hey, Cool!") were mostly the same: the lack of even basic planning meant that work that was done was frequently reworked to the point of being unrecognisable as the original code; IOW, code was effectively thrown away, and not due to changing requirements but due to changes in the project that were forced due to a lack of a basic design.
It simply doesn't work with fuckups (be they drone or Rambo).
In my experience, most processes don't work well with fuckups.
But you are right, good devs figured out processes that work. And like any good dev, they refined them over time and with insight from others. Eventually distilling the process into a methodology...and they called it Agile.
I'm not so sure that that was the process that was followed: I wrote up the majority of this paper over here, and my take is that the smaller groups/companies are flexible enough to try new things. If they die trying then there are still numerous other smaller groups that will try something else. A few generations of this leaves behind only what works (AKA agile). Thus far this is in line with what you say above.
But this evolutionary action only works for small groups (see the references in the above link: one of them finds that agile performs as advertised only for tiny projects); large corporates and/or projects have to have the project designed upfront with at least enough detail to parcel out work to different subgroups. If they started developing without an overall architecture planned they'd mostly just be spinning wheels. For most human endeavors (whether building a house, bridge, automobile or even abstract things like 3D animated movies), a high-level vision is needed, and a high-level architecture. The details are filled in later. Why then do we believe that software, which encompasses the most complex things that humans have ever built, needs less design?
That's literally where all this came from: Great devs, using skill, experience, and creativity, to come up with the best ways to solve very common problem found in very similar situations. And then field testing and refining those solutions into a science.
I beg to disagree on this point: IT (and development) is not yet a science. There's a measurement for this that I forget (scales that measures how close a discipline is to being a science, that is), it was a long time ago that I did basic science reading (The stuff I've been doing the last seven years has not been basic).
The fact is projects, people, companies are much more typical then they are unique. They have the same types of people faced with the same types of problems. Only a bad dev would try and reinvent the wheel for each and every situation. A good dev reuses as much as they possibly can, be it tools, patterns, or processes.
No, I didn't - I said they'll work out what is best; presumably some process that works for them. Dumb devs indeed need to be micromanaged and placed into a process that lets their manager stay on their backs. Smart professionals, whether devs or not, will get annoyed quite rapidly if a manager distrusts the quality of their work.
You still need a process. What Agile basically says is "we're so good or we understand what we're doing so well, we can skip some of the high ceremony." Agile is like a pro athlete cutting corners and making non-fundamental plays because they're good enough to know when it's appropriate.
Needing a process doesn't mean that that process must be agile. For a dev-team that is as good as you say, they certainly won't choose a process that has them micromanaged (what the other pro-agile poster said was that agile is best for poor devs who have to be micromanaged). They'll leave. Any professional that is worth their salt won't put up with helicopter-management.
Look at it from the point of view of a talented professional (never mind the field - think lawyer, doctor, etc). Do you really think that the best surgeon is going to allow himself to be micromanaged by the hospital admin? Or that the best attorney will let the firm's directors mandate micromanagement of him? I've worked with accountants, lawyers and surgeons - they'll very literally leave your establishment if you try to treat them like untrustworthy children. Why do you now expect that devs should be treated like untrustworthy children?
Nope. You can find me everywhere on the net, and I doubt you'll conclude that I'm lazy if you simply search. The fact remains that, if your devs are any good, they've already figured out a good process to use amongst themselves, so no need for agile. If your devs are poor (like the above poster Zenin said - agile is for devs you cannot trust to actually work), then you need agile. The only conclusion that can be drawn from the above is that any shop that practices agile is probably filled with poor devs (the good ones leave - if you treat all your employees like untrustworthy children, pretty soon only the bad ones are left)
So, the real reason is to micromanage? If that's the case then Agile is maybe only suitable if you have undisciplined developers. The rest of us prefer to be dealt with as professionals and grown ups.
BTW: A 15-minute interruption and the resultant loss of context is a big deal when coding. I figure that this sort of interruption doesn't matter to the undisciplined ADHD crowd, but... well, there you go.
But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.
OTOH, if you do have a staff of above-average, disciplined developers and small or well-understood project goals, then what the hell do you need Agile for? If Agile only works for smart disciplined devs, then there's no reason for it (smart devs will work out between themselves what will be best, without needing your help).
Admittedly that's because most do Agile quite wrong. I saw a study somewhere that showed that those that the more Agile processes were followed, the better the success rate. Doing half-assed Agile doesn't work well and burns out developers.
Such a study doesn't exist. The one you're thinking of is the one where they studied agile in action and concluded that using any formal process (such as agile) beats having no formal process. There is no study (none that I've been able to find, at any rate), that was done with a controlled experiment (or even an attempt at one).
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
No one who advocates Agile says that you should just ignore that you have issues until your next standup. Obviously if during the day you have issues you should tell someone. Nice strawman though.
Not a strawman - if you simply discuss issues as they arise, then what's the point of having dailies?
The most important piece of evidence that you should have found is the fact that what you describe is illegal (not only in the US), and that all the other parties have settled this matter admitting guilt rather than proceed with a hearing. You keep ignoring that this practice is illegal, in more countries than the US.
Seem to be two classes of jobs.
1. Those who do real work - The STEM workers, nurses, mechanics, roofers.
2. Those who research, investigate, comment, blog, report, and generally leach of the people in #1.
Yeah, right. Because people like Alan Turing (researcher) leach off people like the average MCSE.
(You're an idiot, in case no one told you this before)
It turns out that BitCoin is not deflationary, as explained in this link.
I read that link. Twice, just to make sure I got it. The link says lots, some of it contradictory, some of which are:
That bitcoin cannot complete a deflationary spiral to the end (Irrelevant - a spiral, once started, doesn't need to end in division by zero - it just needs to get near enough to the end to be worthless)
That even if bitcoin did deflate, it wouldn't matter as long as the bitcoin economy is growiing (false, there is no bitcoin "economy" in the traditional sense as there is nothing of value produced there. A country can have an economy (producing value), while things like bitcoin and the DiabloIII auction house has what we like to call "markets". Bitcoin isn't an economy, it's a market).
That once prices stabilise after a bit of deflation, they will remain stable (This depends on not having the spiral in the first place - essentially their argument is "As long as we don't spiral, we won't spiral". Utter nonsense and circular reasoning)
There are many more where that came from - I urge everyone to read the link just for entertainment - almost like a seasoned politician's spin doctor.
This is exactly the sort of post I'm wondering about. You argue that BitCoin won't work - based on an untruth.
No, he's not. He's relying on the decades of factual research from experts in the field, some of them even nobel prize-winners. In addition, just about anyone who'se even done a cursory glance over an economics textbooks realises at once why bitcoin won't work until it is adopted as an official tender for all purposes in some country. Nothing is a currency until it's defined by a sovereign state
No one who has looked deeply into the concept has come up with a viable reason that it won't work.
Actually everyone has. It's the people like you with dogmatic faith in the system who won't change your mind, for some reason. Hold a lot of bitcoins, do you? made some money of them?
When some gets a worm on your network and it takes the entire business offline for the better part of a day while everyone chases down and cleans the machines you will still say IT failed to do the job you refused to let them do.
The problem with that is that in my experience, even when a worm takes down half the locked-down-to-hell-and-back machines on the network, the IT dept who refuses to let the "peons" do anything still doesn't get blamed! I figure, since you aren't getting blamed when my machine gets infected, why the fuck are you restricting what I can run on it? I get blamed in any case while IT get's to increase their lockdown.
Economic activity and technological progress are rarely linear and tend to occur in spurts, and stops and starts. When a new technology is invented by a particular society (such as the transistor, or manned flight, or the printing press), the value that that society can produce is, for a short but unpredictable period, exponential. In the case of the printing press the value increase was not for a short period at all.
Tangible goods, on the other hand (gold, silver, etc), have a rate of increase in production that is almost always linear, if it increases at all (have we reached peak oil yet?)
Basing a currency on something tangible (gold, silver, pork bellies, etc) means that you either have to throttle your societies output to avoid ridiculous deflation of the currency or spend a significant portion of the new value producing more tangible goods.
That's partly the reason why depressions in countries which have a commodity-backed currency last longer (look it up; it's actually true) - when the actual value being produced is increased, the currency (being based on a monotonically increasing commodity) is unable to keep pace, resulting in a society with more production and value but less actual money.
Another part of the argument for fiat currencies as opposed to commodity currencies is that some countries just naturally have more of the commodities than others - should they then be "richer" than the others even though providing less value to the global society? For example, I live in South Africa, and we produce almost as much gold as the US - do you really think that the US, with all its advanced technology, science and medical knowledge should then be valued the same as South Africa, with all its crime, poverty and unemployment? Under a gold-backed or platinum-backed (or even diamond-backed) currency, this is what will happen. You base you currency in gold and I guarantee that our little country over here in sub-saharan Africa will simply make much of the US our serfs. You will depend on us for money the way most of the world depends on the middle east for oil.
Money's primary function is to measure wealth, not to store it; in much the same way that a ruler is used to measure distance, not to store it. If the only wealth worth measuring comes out the ground, what value will advanced medicine, science and technology have?
(PS. You're correct that having commodity-backed currency means it can't be inflated at will by a ruler, but it also means that the measurable value of the society can't be increased no matter how well they actually do in valuable things like science and tech. A car that prevents the driver from doing stupid things also prevents the driver from doing smart things).
(PPS. I never intended to imply that I underestimate your intelligence - far from it - but I wanted to point out, albeit very painstakingly, that having metal-money only worked when societies progress was just ramping up. Today, there is no product in the world that can keep pace with the state of progress, which is such that mankind is seeing unprecedented rates of increase in value even during times of economic depression!!! Metal money worked well when the increase in the value that society produced was detectable only over centuries. The new things we have now are coming at an ever faster and ever increasing pace - all of this is new value which we never had before, and the money needs to represent it without decreasing in value.)
Over the past 20 years the currency supply as estimated by the Fed themselves has gone from $400 billion to $3,000 billion dollars - a gain of $2,600 billion. That means 6.5 times more US currency than *existed* 20 years ago has been *added* to the supply since then, and that's *net* so gross numbers would be even bigger.
As long as the value produced by the country in question increased by the same ratio, there is no problem. You are working on the assumption that the increased science, increased technology, increased production of goods, increased production of ideas, concepts, arts, literature and all the rest; that all those things that have increased that give a currency its value in the world; that those things have not kept pace with the increased amount of bills floating around. Perhaps you're right, but I get the impression that you never even considered it.
For my part, where I am, the increase in value I've seen has largely outpaced the decrease in the currency's worth.
Modern languages like Dart and C# allow you do do some pretty functional style programming. Maybe you should check them out. You might like them.
That's just the thing - I have checked them out, and I have used them, and I like them just fine, so I'm not talking down at you from some ivory tower place. You really should look at the research being done with regards to human learning and cognition to understand why the current programming languages (very few new concepts in the last 20 years or so) have not kept pace with what we now know. Stagnation is not good, else we would've evolved assembler to brainfuck, and not C.
Your argument seems to be that it's okay to be using concepts from 20 years, or even 25 years ago, because what we knew then is still state of the art right now. Even the semantic web people (as hopeless as I think their research is) are trying new things. Your argument is based purely on emotion: this is what you like therefore it must be good. Current evidence isn't in your favour, which you would know had you even bothered to look it up.
Finally, you're pretty inexperienced, and me saying that is not meant to be an insult, just to highlight where your actual shortcomings are in this discussion. You are arguing from the position that you have no shortcomings, but something like inexperience is pretty easy to spot. I'm not going to reply anymore - you clearly won't change your mind no matter how many researchers publish their findings (yeah, I did language research for a few years at a science research facility, so I've read most of the publications dealing with this), and you haven't even attempted to find any programming-languages publication to check if I'm talking horseshit or actually repeating what various well-respected scientists are saying: you feel your few years of programming are enough to make you an expert, nevermind those people who devoted decades to studying just this and nothing else. So... no point in replying to you. Take care.
I'm only trying to figure out what you want. Programming languages are too hard and your example of something that can be done differently is Lisp? Lisp, which is even harder for a human and easier for a lexer than C, is your shining example?
Nope. Lisp is harder for those programmers already indoctrinated into imperative programming. Google for the studies that show languages like scheme being easier for people who have never programmed before. The only reason you find lisp-like syntax hard is because you are looking for all those deficiencies (like static, and commas) that you are used to.
What makes you think arguments/parameters are a list?
Because that's exactly what they are. I don't care if you can claim they are something else. It is a list.
Of course it's a list if all you know are lists - they may make more sense as a set, or a dictionary, but you wouldn't find out about that if you insist that they have to be a list. Of course it's a list if your definition of "arguments" is "list"
I suppose you might think differently after you get some experience under your belt. I thought pretty much the same way when I was a newbie at programming too.
Trite, passive-aggressive insult aside, what do you think now? Make a fully formed thought about how to make programming "better".
Now I know better - you want static and commas only because that's all you know. Many experiments and studies on the human mind show that (for example) OO is completely unintuitive to the human mind (random example - look up Donald E. Normans papers on Man/Machine interfaces).
Your examples have been shown as nonsense (or already implemented).
Nope - All you've done is say that imperative languages can't do without these thigns, which is not what I was arguing anyway - imperative languages need these crutches because of their deficiencies. GP posted a lot of insightful thoughts on this, which you dismissed with the fully untrue "already been done". Do yourself a favour and just experiment with implementing a large non-trivial system in (for example) Erlang.
You want things "easier" but you have no idea how to do that; you just want someone else to do it. Now when someone tells you why things are the way they are you stamp your feet and make insults.
I'm sorry that you really are inexperienced, but only you
You claim to have implemented some languages in your time but you haven't shown much understanding of the theory behind it.
I've got all the experience and math theory behind all the automata and turing-completeness and all the other buzzwards, which is why I've experimented with different languages (both using and designing and implementing). One day you will, too.
Slashdot Mirror
I've got one of those; easily the most convenient watch I've ever owned; battery recharges from sunlight, apparently. I say "apparently" because it's never been down to zero charge. The cost/time/efort in changing batteries once a decade is worth the extra expense of having a non-battery watch.
You know the reason that home PCs with humble specs can run the latest 3D games? Because they're also being developed for 10 year old consoles. Developers don't spend a lot of money in porting their 3D console games to the PC, hence the PC required for gaming has been relatively static for quite a while.
Now there are new more powerful consoles for people to develop games for.
Which, even if perfectly developed for, are still about a tenth as powerful as a gaming rig, and about half as powerful as the cheapest beige box there is. For the price of a new-gen console and 1 game, you would probably get a PC and perhaps 4 games of comparable performance.
If the dev considers collaborating well with others, taking ownership and responsibility of their own talents and shortcomings, being accountable to their team mates. If a dev considers such things to be akin to "treated like a child", perhaps the dev is still a child.
The fact is a lot of developers got into software because they could retreat into their own cave and not have to grow up. Not have to learn to work and play well with others.
Waterfall et al are all about micromanaging a schoolyard full of undisciplined developers. Agile is for adults, it requires a strong sense of personal responsibility that frankly a lot of devs just don't have.
--
The fact is Agile is the polar opposite of micromanaging. And that is why a lot of devs don't like, they can't stand the responsibility.
To be honest, in the twenty+ or so agile projects I've been on, it's only been the poor devs who like it. It allows them to spin wheels for weeks, knowing that any crap they write (magic numbers, strange assumptions about runtime, no error-handling, etc) will in all probability get thrown away anyway.
Re micromanaging: Devs who take full responsibility for what they do won't be micromanaged. Those who like CYA prefer it, as it gives them an out. THe sad fact remains that, in the decade or more since agile became popular, software failure rates have gone up, not down. No matter how vehemently you argue that it's better, the fact that it's correlated with failure still remains.
This thread is old, so I probably won't be replying again.
President: 4 months?!?! In that case lets have cake... and hookers... and blow!
In that case, forget about the cake.
There is no need for a well thought-out plan. It's agile.
You've made two wrong assumptions.
Where in my comment do I say "wait until dailies to communicate"? I asked "what's the point of dailies if you're already communicating?"
Honestly, the biggest problem with agile is dealing with the fundamentalists; much like creationists, they've got specific arguments that they've been rehearsing with the rest of the flock, like the kneejerk response I quoted above. The other similarity that agile has with jehovas witnesses and other nutcases is when you point to specific instances of it not working. Rather than concede that it doesn't work, they just shift the blame to the practitioner.
Ever consider that perhaps the smart folk avoid the agile folk simply because they don't want to talk religion?
And yet the reality is exactly the opposite: Agile methods are by strong people, for strong people.
That wasn't my experience of agile... at all!? The most memorable one was when I was part of a dev-team on a postgrad course. Team leader insisted on agile, and then insisted that the (relatively tiny) project be done only when we're all together in the same room (we lived about 60km apart from each other in a rough triangle). He then insisted that we meet and work on the project (tiny one for postgrad module) two hours a day every day after work, with sixteen hours each weekend over a two month period and insisted that no telecommuting would be allowed. I left the team (and halted my MS temporarily); last I heard they actually did stick to the proposed schedule but failed the course anyway.
My other experiences with agile development (bear in mind that I approached this as I approached most new things: "Hey, Cool!") were mostly the same: the lack of even basic planning meant that work that was done was frequently reworked to the point of being unrecognisable as the original code; IOW, code was effectively thrown away, and not due to changing requirements but due to changes in the project that were forced due to a lack of a basic design.
It simply doesn't work with fuckups (be they drone or Rambo).
In my experience, most processes don't work well with fuckups.
But you are right, good devs figured out processes that work. And like any good dev, they refined them over time and with insight from others. Eventually distilling the process into a methodology...and they called it Agile.
I'm not so sure that that was the process that was followed: I wrote up the majority of this paper over here, and my take is that the smaller groups/companies are flexible enough to try new things. If they die trying then there are still numerous other smaller groups that will try something else. A few generations of this leaves behind only what works (AKA agile). Thus far this is in line with what you say above.
But this evolutionary action only works for small groups (see the references in the above link: one of them finds that agile performs as advertised only for tiny projects); large corporates and/or projects have to have the project designed upfront with at least enough detail to parcel out work to different subgroups. If they started developing without an overall architecture planned they'd mostly just be spinning wheels. For most human endeavors (whether building a house, bridge, automobile or even abstract things like 3D animated movies), a high-level vision is needed, and a high-level architecture. The details are filled in later. Why then do we believe that software, which encompasses the most complex things that humans have ever built, needs less design?
That's literally where all this came from: Great devs, using skill, experience, and creativity, to come up with the best ways to solve very common problem found in very similar situations. And then field testing and refining those solutions into a science.
I beg to disagree on this point: IT (and development) is not yet a science. There's a measurement for this that I forget (scales that measures how close a discipline is to being a science, that is), it was a long time ago that I did basic science reading (The stuff I've been doing the last seven years has not been basic).
The fact is projects, people, companies are much more typical then they are unique. They have the same types of people faced with the same types of problems. Only a bad dev would try and reinvent the wheel for each and every situation. A good dev reuses as much as they possibly can, be it tools, patterns, or processes.
-
We agree on this :)
And there are reasons th
Agile methods exist since 20 years.
When they got established there where hundrets of studies that show that being more agile helps to be more successful.
There are no studies that support that statement, which is what I originally said.
No, I didn't - I said they'll work out what is best; presumably some process that works for them. Dumb devs indeed need to be micromanaged and placed into a process that lets their manager stay on their backs. Smart professionals, whether devs or not, will get annoyed quite rapidly if a manager distrusts the quality of their work.
So wait, are you saying that because there's no evidence that agile is worse, it must be better? That's crazy talk.
You still need a process. What Agile basically says is "we're so good or we understand what we're doing so well, we can skip some of the high ceremony." Agile is like a pro athlete cutting corners and making non-fundamental plays because they're good enough to know when it's appropriate.
Needing a process doesn't mean that that process must be agile. For a dev-team that is as good as you say, they certainly won't choose a process that has them micromanaged (what the other pro-agile poster said was that agile is best for poor devs who have to be micromanaged). They'll leave. Any professional that is worth their salt won't put up with helicopter-management.
Look at it from the point of view of a talented professional (never mind the field - think lawyer, doctor, etc). Do you really think that the best surgeon is going to allow himself to be micromanaged by the hospital admin? Or that the best attorney will let the firm's directors mandate micromanagement of him? I've worked with accountants, lawyers and surgeons - they'll very literally leave your establishment if you try to treat them like untrustworthy children. Why do you now expect that devs should be treated like untrustworthy children?
I think we detected the Rambo in the group.
Nope. You can find me everywhere on the net, and I doubt you'll conclude that I'm lazy if you simply search. The fact remains that, if your devs are any good, they've already figured out a good process to use amongst themselves, so no need for agile. If your devs are poor (like the above poster Zenin said - agile is for devs you cannot trust to actually work), then you need agile. The only conclusion that can be drawn from the above is that any shop that practices agile is probably filled with poor devs (the good ones leave - if you treat all your employees like untrustworthy children, pretty soon only the bad ones are left)
So, the real reason is to micromanage? If that's the case then Agile is maybe only suitable if you have undisciplined developers. The rest of us prefer to be dealt with as professionals and grown ups.
... well, there you go.
BTW: A 15-minute interruption and the resultant loss of context is a big deal when coding. I figure that this sort of interruption doesn't matter to the undisciplined ADHD crowd, but
But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.
OTOH, if you do have a staff of above-average, disciplined developers and small or well-understood project goals, then what the hell do you need Agile for? If Agile only works for smart disciplined devs, then there's no reason for it (smart devs will work out between themselves what will be best, without needing your help).
Admittedly that's because most do Agile quite wrong. I saw a study somewhere that showed that those that the more Agile processes were followed, the better the success rate. Doing half-assed Agile doesn't work well and burns out developers.
Such a study doesn't exist. The one you're thinking of is the one where they studied agile in action and concluded that using any formal process (such as agile) beats having no formal process. There is no study (none that I've been able to find, at any rate), that was done with a controlled experiment (or even an attempt at one).
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
No one who advocates Agile says that you should just ignore that you have issues until your next standup. Obviously if during the day you have issues you should tell someone. Nice strawman though.
Not a strawman - if you simply discuss issues as they arise, then what's the point of having dailies?
The most important piece of evidence that you should have found is the fact that what you describe is illegal (not only in the US), and that all the other parties have settled this matter admitting guilt rather than proceed with a hearing. You keep ignoring that this practice is illegal, in more countries than the US.
Seem to be two classes of jobs. 1. Those who do real work - The STEM workers, nurses, mechanics, roofers. 2. Those who research, investigate, comment, blog, report, and generally leach of the people in #1.
Yeah, right. Because people like Alan Turing (researcher) leach off people like the average MCSE.
(You're an idiot, in case no one told you this before)
It turns out that BitCoin is not deflationary, as explained in this link.
I read that link. Twice, just to make sure I got it. The link says lots, some of it contradictory, some of which are:
That bitcoin cannot complete a deflationary spiral to the end (Irrelevant - a spiral, once started, doesn't need to end in division by zero - it just needs to get near enough to the end to be worthless)
That even if bitcoin did deflate, it wouldn't matter as long as the bitcoin economy is growiing (false, there is no bitcoin "economy" in the traditional sense as there is nothing of value produced there. A country can have an economy (producing value), while things like bitcoin and the DiabloIII auction house has what we like to call "markets". Bitcoin isn't an economy, it's a market).
That once prices stabilise after a bit of deflation, they will remain stable (This depends on not having the spiral in the first place - essentially their argument is "As long as we don't spiral, we won't spiral". Utter nonsense and circular reasoning)
There are many more where that came from - I urge everyone to read the link just for entertainment - almost like a seasoned politician's spin doctor.
This is exactly the sort of post I'm wondering about. You argue that BitCoin won't work - based on an untruth.
No, he's not. He's relying on the decades of factual research from experts in the field, some of them even nobel prize-winners. In addition, just about anyone who'se even done a cursory glance over an economics textbooks realises at once why bitcoin won't work until it is adopted as an official tender for all purposes in some country. Nothing is a currency until it's defined by a sovereign state
No one who has looked deeply into the concept has come up with a viable reason that it won't work.
Actually everyone has. It's the people like you with dogmatic faith in the system who won't change your mind, for some reason. Hold a lot of bitcoins, do you? made some money of them?
When some gets a worm on your network and it takes the entire business offline for the better part of a day while everyone chases down and cleans the machines you will still say IT failed to do the job you refused to let them do.
The problem with that is that in my experience, even when a worm takes down half the locked-down-to-hell-and-back machines on the network, the IT dept who refuses to let the "peons" do anything still doesn't get blamed! I figure, since you aren't getting blamed when my machine gets infected, why the fuck are you restricting what I can run on it? I get blamed in any case while IT get's to increase their lockdown.
Economic activity and technological progress are rarely linear and tend to occur in spurts, and stops and starts. When a new technology is invented by a particular society (such as the transistor, or manned flight, or the printing press), the value that that society can produce is, for a short but unpredictable period, exponential. In the case of the printing press the value increase was not for a short period at all.
Tangible goods, on the other hand (gold, silver, etc), have a rate of increase in production that is almost always linear, if it increases at all (have we reached peak oil yet?)
Basing a currency on something tangible (gold, silver, pork bellies, etc) means that you either have to throttle your societies output to avoid ridiculous deflation of the currency or spend a significant portion of the new value producing more tangible goods.
That's partly the reason why depressions in countries which have a commodity-backed currency last longer (look it up; it's actually true) - when the actual value being produced is increased, the currency (being based on a monotonically increasing commodity) is unable to keep pace, resulting in a society with more production and value but less actual money.
Another part of the argument for fiat currencies as opposed to commodity currencies is that some countries just naturally have more of the commodities than others - should they then be "richer" than the others even though providing less value to the global society? For example, I live in South Africa, and we produce almost as much gold as the US - do you really think that the US, with all its advanced technology, science and medical knowledge should then be valued the same as South Africa, with all its crime, poverty and unemployment? Under a gold-backed or platinum-backed (or even diamond-backed) currency, this is what will happen. You base you currency in gold and I guarantee that our little country over here in sub-saharan Africa will simply make much of the US our serfs. You will depend on us for money the way most of the world depends on the middle east for oil.
Money's primary function is to measure wealth, not to store it; in much the same way that a ruler is used to measure distance, not to store it. If the only wealth worth measuring comes out the ground, what value will advanced medicine, science and technology have?
(PS. You're correct that having commodity-backed currency means it can't be inflated at will by a ruler, but it also means that the measurable value of the society can't be increased no matter how well they actually do in valuable things like science and tech. A car that prevents the driver from doing stupid things also prevents the driver from doing smart things).
(PPS. I never intended to imply that I underestimate your intelligence - far from it - but I wanted to point out, albeit very painstakingly, that having metal-money only worked when societies progress was just ramping up. Today, there is no product in the world that can keep pace with the state of progress, which is such that mankind is seeing unprecedented rates of increase in value even during times of economic depression!!! Metal money worked well when the increase in the value that society produced was detectable only over centuries. The new things we have now are coming at an ever faster and ever increasing pace - all of this is new value which we never had before, and the money needs to represent it without decreasing in value.)
Over the past 20 years the currency supply as estimated by the Fed themselves has gone from $400 billion to $3,000 billion dollars - a gain of $2,600 billion. That means 6.5 times more US currency than *existed* 20 years ago has been *added* to the supply since then, and that's *net* so gross numbers would be even bigger.
As long as the value produced by the country in question increased by the same ratio, there is no problem. You are working on the assumption that the increased science, increased technology, increased production of goods, increased production of ideas, concepts, arts, literature and all the rest; that all those things that have increased that give a currency its value in the world; that those things have not kept pace with the increased amount of bills floating around. Perhaps you're right, but I get the impression that you never even considered it.
For my part, where I am, the increase in value I've seen has largely outpaced the decrease in the currency's worth.
If I do not work why should I be punished(through inflation) for having set some money aside?
Because you aren't contributing to the growth that occurred between the time you set that money aside and the time you realised it's worth less.
Modern languages like Dart and C# allow you do do some pretty functional style programming. Maybe you should check them out. You might like them.
That's just the thing - I have checked them out, and I have used them, and I like them just fine, so I'm not talking down at you from some ivory tower place. You really should look at the research being done with regards to human learning and cognition to understand why the current programming languages (very few new concepts in the last 20 years or so) have not kept pace with what we now know. Stagnation is not good, else we would've evolved assembler to brainfuck, and not C.
Your argument seems to be that it's okay to be using concepts from 20 years, or even 25 years ago, because what we knew then is still state of the art right now. Even the semantic web people (as hopeless as I think their research is) are trying new things. Your argument is based purely on emotion: this is what you like therefore it must be good. Current evidence isn't in your favour, which you would know had you even bothered to look it up.
Finally, you're pretty inexperienced, and me saying that is not meant to be an insult, just to highlight where your actual shortcomings are in this discussion. You are arguing from the position that you have no shortcomings, but something like inexperience is pretty easy to spot. I'm not going to reply anymore - you clearly won't change your mind no matter how many researchers publish their findings (yeah, I did language research for a few years at a science research facility, so I've read most of the publications dealing with this), and you haven't even attempted to find any programming-languages publication to check if I'm talking horseshit or actually repeating what various well-respected scientists are saying: you feel your few years of programming are enough to make you an expert, nevermind those people who devoted decades to studying just this and nothing else. So ... no point in replying to you. Take care.
I'm only trying to figure out what you want. Programming languages are too hard and your example of something that can be done differently is Lisp? Lisp, which is even harder for a human and easier for a lexer than C, is your shining example?
Nope. Lisp is harder for those programmers already indoctrinated into imperative programming. Google for the studies that show languages like scheme being easier for people who have never programmed before. The only reason you find lisp-like syntax hard is because you are looking for all those deficiencies (like static, and commas) that you are used to.
What makes you think arguments/parameters are a list?
Because that's exactly what they are. I don't care if you can claim they are something else. It is a list.
Of course it's a list if all you know are lists - they may make more sense as a set, or a dictionary, but you wouldn't find out about that if you insist that they have to be a list. Of course it's a list if your definition of "arguments" is "list"
I suppose you might think differently after you get some experience under your belt. I thought pretty much the same way when I was a newbie at programming too.
Trite, passive-aggressive insult aside, what do you think now? Make a fully formed thought about how to make programming "better".
Now I know better - you want static and commas only because that's all you know. Many experiments and studies on the human mind show that (for example) OO is completely unintuitive to the human mind (random example - look up Donald E. Normans papers on Man/Machine interfaces).
Your examples have been shown as nonsense (or already implemented).
Nope - All you've done is say that imperative languages can't do without these thigns, which is not what I was arguing anyway - imperative languages need these crutches because of their deficiencies. GP posted a lot of insightful thoughts on this, which you dismissed with the fully untrue "already been done". Do yourself a favour and just experiment with implementing a large non-trivial system in (for example) Erlang.
You want things "easier" but you have no idea how to do that; you just want someone else to do it. Now when someone tells you why things are the way they are you stamp your feet and make insults.
I'm sorry that you really are inexperienced, but only you You claim to have implemented some languages in your time but you haven't shown much understanding of the theory behind it.
I've got all the experience and math theory behind all the automata and turing-completeness and all the other buzzwards, which is why I've experimented with different languages (both using and designing and implementing). One day you will, too.