- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
If you treat the methodology as infalable it is garanteed to fail.
This is what put me of XP rather rapidly. Yes I agree that there is no magic bullet which will make IT cheap, easy and fast. If creating software was that simple we would have programs to write all our programs by now and actual programming would be a lost art.
I for one favor a more moderate Agile approach. WHich has just enough documentation, a healthy set of Tests which test what can be automatically tested, and a minimisasion of components which can't be automatically tested.
As a futher asside yes the analogy is fairly shaky, but hay it is an analogy, they all break if you push things far enough.
captcha pirates (The flying spagetti monster was here)
Admin
One of agile development basic rules is refactor mercilessly. This means, that failures along the way have chance of being fixed up, while in waterfall model there's little room for changing things that turned out wrong.
However it:
Requires that the programmers recognize the failures.
The manager actually allows them to refactor. Usually even if the programmers realize a failure, the manager only sees fixing it as lost time and will forbid doing it.
Admin
Nonsense. Open source is about freedom, not price.
Admin
You're so wrong here, on so many levels...
Admin
Refactoring does not necessarily mean that you fix failures. The original code might have been perfectly valid at the time it has been written, but because of continuous changes, it has reached a point where a alteration is necessary. For example, a method starts small, but as more and more details are added, it becomes too large and should be broken into smaller parts.
Admin
"Good people can build good software no matter what methodology they use."
I don't think so. Good people can build good software no matter what methodology they use when they stick to it.
The difference between CMMI and Scrum for example is, that there are hundreds of pages for CMMI which you have stick to and 5 rules for Scrum which you have stick to. Guess which methodology people can easier follow? Beside that, agile methodologists think that agile works fine together with CMMI and other "heavy" process models.
And most agile methodologies (Scrum, Crystal, ...) don't say anything about how good people need to be (well non agile users most often only know XP or mean XP when they use the word agile and deduce from there that agile methodologies only work with good people).
Admin
"One of agile development basic rules is refactor mercilessly."
This is not a basic agile rule, whereever you got that idea from. This is a XP rule, where XP is a methodology which formed the term agile but so far has been quite unsuccessfull because of the mixture of technology and managment practices. Most other agile methodolgies don't say anything about technology or development techniques like pair programming, unit testing or refactoring. This was a XP only, and a bad one, most agile practioneers think today.
Admin
Bzzt, category mistake. There are somethings iterative development are good for creating. Those things are called "programs". Agile is not a "program".
Even if you wanted to somehow "refactor" Agile, what sort of methodology would you use? Perhaps some kind of genetic algorithm? Why don't you "refactor" that, too? How would you choose to?
It's turtles all the way down. Diagonalization makes turtles happy.
Now, this doesn't mean there isn't room for variation. There are plenty of kinds of Agile programming. See http://en.wikipedia.org/wiki/Agile_Programming#Agile_methods
Admin
I strongly suspect that everyone here who's scoffing at development methodologies and harping on how the real point is that other programmers aren't good enough has just never been involved in a really large and complex development project.
Admin
I prefere to fire the bad programmer.
Admin
"Monochrome" means single-coloured. CGA stands for Colour Graphics Adaptor. They're 2 different things. One for monochrome displays. One for colour displays (even though the number of colours is very limited -- 16?). How come you can mix these 2 things together as "monochrome CGA"?
"Monochrome" can actually refer to 2 things at that time. 1) The MDA (Monochrom Display Adaptor) can only display text and in only 1 colour (amber/green/white, depending on the type of phosphor used on the monitor) besides black, but can highlight text using a brighter colour, underlining, blinking or a combination of these. 2) A successor called Hercules card is backwards compatible with MDA, and also has graphics modes (single-coloured, though), allowing high resolution graphs to be plotted.
CGA, the alternative to monochrome, could display both text and graphics in a limited number of colours. It's resolution is lower, though. So, many offices opted for the MDA for better resolution, because the computer operation has to operate the machine for long hours. (Monochrome monitors are also cheaper.)
Admin
Slap a front and back cover on this and get it to O'Reilly.
(Try not to let them post a sample chapter, though...)
Admin
There was a point made in that article that great programmers should realise they're great and help others. I used to work for a company that wanted a TRAINEE software developer. They offered full training. Their training was heres google off you go. Now obvioulsy I sucked at it and needless to say I dont work there any more.
From my experience experienced programmers don't seem to be too interested in helping others become good at all. All they seem to be interested is making themselves look even better at the expense of their colleagues. Ok in my case it was a little bit extreme. But I've heard of similar cases from hundreds of people across the UK. I now work in IT support because of this as I've not managed to find a developer willing to invest time in training someone to be on their level.
Apologies for a kind of sweeping comment I'm sure there are thousands of exceptions.
Just wondered what other peoples experiences were
Admin
Imagine Menkaure's son Shepseskaf completing his father's pyramid after his death.
Or perhaps Neferirkare: "But he died before the complex was completed. The work on the pyramid was stopped, and the funerary complex quickly finished, using mudbrick and tree instead of stone." (But good old Nyuserre later refactored it for his dear ol' dad.)
Not sure what my point is.
Admin
Agile methods are like any other tool. If you use it incorrectly you're gonna get hurt! Agile methods DOES NOT mean that you throw planning out the window. It does not mean you cobble together a system. It just a different way of building the system, a way that (wait for it) responds well to change and often allows the user to give feedback earlier and more often than with traditional methods - avoiding the classic "Thats what I wanted, but not what I need" scenario (look up "requirements analysis).
Agile methods work well - if used responsibly and not as an excuse to produce poorly documented, poorly designed and poorly built software systems.
Admin
I'm currently working in the IT-Department of a insurance company. Amongst others, we use mainframes to run our applications.
I just recently overheard my colleagues talking about technology fads. First they started âbout AI and how management thought it would make IT people obsolete. To which I silently agreed. Then they talked about the java-courses they had so many years ago and how management OO-Programming would change the way IT would work. They dismissed it as a fad too. I remained silent.
OO and Java were both hyped strongly, but it still have some merits. It makes programming easier for some projects (especially larger ones). It doesn't deserve to be dissed the same as AI. Still for some people it's just the same type of fad.
I thought to talk to them and explain them the merits of OO. The problem is, its almost impossible to explain when the other person has never tried it. My guess with agile development is, that it supports some very good technologies (like SVN and Unit-testing) and that you can't really judge it, if you never tried it.
But then educating other people about being a better programmer? Who are you kidding? Are you going to be the arrogant prick running around telling other people how to do their job? And even if you are right, why should they begin to improve? I know so many programmers who take pride that they don't pick up a book to learn and who don't want learn anything outside their job or a outside a paid course.
The only thing you can do is to lead by example. Try to be a good programmer and try to improve. If you do a good job, people who are interested in becoming better themselves will come and ask what you different than others.
Admin
There is a huge difference between the attitude of people who worked in a successful agile project and those who were just nicked for some money by a consultant firm. Now comes my experience, sorry consultants:
Agile does not work for average people. It just helps good people cooperate with each other without the average mass behind them. Good developers not always have perfect people-skills. Sometimes they have a big ego, so it's more comfortable for them to work among less-skilled developers.
Did you try to get Picasso and Monet to work on the same painting? This is the only thing these methodologies solve: to get the focus back on rational arguments instead of fighting with each other. This way you do not need 10 average developers per a good one to provide a kingdom for them, which helps efficiency in the end.
Admin
James, i absolutely agree, this is the biggest problem in IT.
it can derail any methodology, adoption of new technology, or even a "normal, everyday" project for a company
Admin
Well Alex,
"eat less" still cannot work. The problem is what you eat. It depends on the amount of energy the food gives you over time and how full your stomach feels. If this amount is less than the energy you actually need, you'll get thinner. if not you will be fat soon. Now "normal" food is really bad because it consists of very simple (short) carbohydrates like kinds of sugar, starch, white flour. They get splitted into sugar very quickly, go into the blood very quickly, and because too much sugar is toxic for your blood (see diabetes) your body uses insulin to move the sugar very quickly out of the blood and into your fat cells. So the longer the carbohydrates, the longer it takes to digest the same amount of energy.
So it's NOT the fat has to be avoided. It's the short carbohydrates, and most of the time the sugar and white flour (which btw is a completely dead conserve).
For the fat there is another simple rule. The lower the viscosity, the more unsaturated it is, the more healthy it is, because that's the fat that you need to digest certain vitamines or to lose weight. (That's why margarine - whlie made from unsaturated oil - is very saturated, and therefore bad. Else it woil not be solid!)
Now all this would make you thinner... but still very sick. The reason for this again is that you need to maximise the variation of your food to maximise your health. And i mean all variations of proteins, vitamines, minerals, trace elements, fibers, ... te deliver all kinds of building blocks to repair your body and grow some muscles and immune system cells.
And last but not least never but never forget those 3 rules:
Good luck! :D
Admin
This kind of arrgance (People who think of themselves as comparable to Picasso and everyone else as "less skilled") is exactly what ruins projects, and the methodology to solve it is not "agile", it's not hiring such people for any project they can't complete on their own. In a project of any real size, egomaniacs hurt far more than they help, no matter how "good" they technically are (which is usually not nearly as good as they think). The solution is to dump them and find people who are good AND have people skills so they can help you average programmers be productive rather than use them to stroke their ego.
Admin
Sure, attack the metaphor, and display your ignorance while doing so.
Somebody didn't play with enough building blocks as a child - that building scheme extends trivially into three dimensions. No foundations required if you build it on solid bedrock. Well, they're not that complex in most pyramids. The pharaoh's tomb is basically in the middle, and the tunnels are straight, sufficiently so that people believe that they follow sight-lines from the pharaoh to particular stars*.Admin
Other things (rate of absorption, etc.) may affect other important aspects of your health, but your weight is almost entirely down to calorific balance.
Admin
(maybe) random thoughts after reading the post:
Agile is not meant for the "less than good". Processes and tools, were invented so that average people would have some reliable way of dealing with a vast quantity of small, hard to remember, not always applicable, details. Relying instead on people interaction seems to be a strategy where you expect people to be capable to directly deal those details. Most can't "by the very definition of the word "good""
Because it is not meant for the average does not mean it is useless for the good. Getting rid of "for dummies" processes and tools makes sense for people that are actually slowed by those things. Of course the end result has to be the same, and accountably so (or at least the customer must believe it is the same)
Because it is meant for the good will maybe boost up the spirits of the average subjected to it. Maybe this will make them more efficient. If so, why not think that the same boost could be achieved by having processes that are less "do it exactly like this, you stupid !" and more "in case you don't remember what to do in this case, try this" ?
Because the Agilists are making a great business selling us dummies their credo, does not make them bad. They exploit the natural resources around. Thanks Alex for pointing this out: as with miracle diets, the evil is within us, not within the product we childishly by to feel better and avoid looking for the real causes of our discomfort.
Admin
First off, it was 4 colors not 16 (EGA had 16).
Secondly, what the OT refers to, is probably just that - a computer with CGA card attached to a monochrome monitor. It was pretty standard and not even for Soviet PC clones (like Iskra (or "spark" in English)), but also for various other PC clones like Olivetti PC XT I used to sit at when I was around 5 years old.
Admin
Actually, I do not think that the barrier of entry is too low, but rather the barrier of exit (so to speak), is too high. It is understood that a fresh-out-of-school programmer may do dumb things, make stupid mistakes, and likely not be the best person to architect a system.
However, it is not understood that just because someone has been around the block a few times, that it should be assumed that they are doing quality work. I have seen lots of "principal developers" doing dumb/stupid things that I stopped doing 3 years out of school. There tends to be very little controls in place to get these kinds of developers out of the company.
I think that all developers should have their code go through some kind of peer-review. XP and other Agile processes mandate this, so that is at least a step in the right direction, IMHO.
Admin
Rather than try to educate the uneducatable, wouldn't it be easier to just not hire incompetent coders in the first place?
Admin
I like how Alex equates thin people with good programmers, and says fat people plain suck at programming.
Because it's true.
Admin
Quite a misconception this one, that standards will make up for the lack of skilled workers. Well, they aren't.
Truth is, there is far more work to do than skilled people are there ever going to be. This is not floor mopping, where 90% are skilled enough; we're talking about CS, where we try to make software precisely to solve problems that no average person is able to solve easily.
Far gone are the times when software did the same a person would, just did it faster. Now, we want software to work both faster and better than the user would. We want software the average end-user will never completely understand, and more and more often the average programmer will neither (think API, libraries, copy&paste).
So, by definition of CS itself and what we expect from it, either you also employ the not-so-skilled, the average and under-average, and you plan for integrating them into your production processes... or you just end up with a gross and ever-increasing lack of skilled labor.
Admin
Admin
Wait!!! There are business that know this shit?? Where? WHO?!?!! Sounds like Bizaro land to me.
Agile was born because business do not know what they want to build and the always change their mind during the construction.
You trying telling your architect that you want to increase the ground floor space when the roof is going on.
Actually, I fuckin' hate software-property building analogies.
Admin
eh, the iterations? the bit where the client gets to see regular drops? frequent client communication? low cost of change?
http://www.digitalfocus.com/_includes/pop_agile_vs_waterfall.html
Admin
I'm sorry... I can't let this inaccuracy go by. You've used the definition of "median" where you said "average," which means the arithmetic mean. The median is the value that 50% of your samples fall below. The average is the sum of all values divided by the number of samples.
Here's an example: I have 5 people whose IQs are 100, 100, 100, 100, and 10. The average IQ is 82. In this case, 80% of my people are above-average! But the median would be 100, which is clearly more representative of the data...
I'd say I'm just being pedantic, and of course part of me is doing just that -- but I truly believe that this kind of miscommunication is exactly what leads to inaccurate requirements, coding errors, and the like. All the Agile in the world will never overcome inaccurate communication...
Admin
Reading the comments here gives me a feeling of nostalgia.
Many people disparage "agile" without ever having experienced an agile project; their arguments are based on assumptions and, in some cases, the logical fallacy known as the Strawman (e.g., "Since agile is marketed as a religion, blah blah blah").
Many others respond to this by accusing the first group of promoting "waterfall" methods; their arguments are based on the logical fallacy known as the False Dilemma (e.g., most of those who have doubts about agile methods are interested in effective alternatives to the waterfall, they just aren't convinced that agile works).
These arguments are so far out of date, they make me feel young again. Thanks for that!
Admin
"A real computer scientist never programs in anything less portable than a number 2 pencil."
Admin
Turns out that pyramids in Egypt are built upon older ones, at least for the oldest one. Don't you watch the Discovery channel?
Admin
Actually, what this indicates is that analogies generally suck at giving you insight into an issue and may actually misinform.
Admin
<pedantic_rant> The word is METHOD. Sure, you can redefine the meaning of methodology from "the study of methods" to mean "method", but WHAT IS THE POINT? Yeah, maybe it's been put into dictionaries now, or it's in wikipedia or some other crap, it's still a pointless word. If I were to be cliche, I'd say some about TRWTF... </pedantic_rant>
Admin
I mean to start and conclude by saying this analogy is fallacious because pyramids are not built that way.
In the agile case, you are layering ontop of a finished pyramid. However, a pyramid like the Great Pyramids at Cheops is a step pyramid of square blocks covered - when finshed - by regular prisms called casing stones. These stones are meant to be polished smooth and whitewashed (painted brilliant white with a simple led paint.)
Each 'finished' smaller pyramid would have to be built on top of these smooth layers. They could not be built at all for reasonable effort even given a Pharaoh's significant labor pool. If built, these larger pyramids would be fragile rinds on the outside of a building.
And to top it off, like the casing stones, the next conquerer to pass through the project would just rip off the nice outer layers to make their fancy buildings. This was done by Napoleon and the Moors to the Great Pyramids.
Come to think of it, this sounds a lot like real-world development. Maybe it is a good model after all. Projects reusing half-assed APIs and tools not built with reuse in mind. Pillaging previous projects to jump start existing ones. Bad Software Engineering as a method of tacky veiner piled upon tacky veiner piled upon something that actually worked for someone, somewhere.
CAPTCHA: ewwwww, how I feel about this Agile Metaphor.
Admin
Nobody every said they should use the waterfall model. There is more out there than waterfall and agile development.
I think what alex wants to make a point is that you need to know the outline, the outcome of the whole project to start with so you can have sombody, preferable good, to make the framework for the project. After you build that base you can use the agile methods as well as others to create the business logic in whatever suits best to the given situation
Admin
This article is full of fail.
Flawed analogy.
Author demonstrates little comprehension of subject matter.
Article fails at being helpful to newer programmers.
Get some perspective. This nonesense is the epitome of WTF.
Admin
Just because you can't do everything 100% Agile doesn't mean that you should chuck the whole thing out the window. I believe that the best way to develop is sort of a compromise between Agile and Waterfall-like methodologies.
For example, you do need to have an overall plan for what you are doing. However, once you have an overall plan, there's no reason that you can't factor that plan out into many stages, with each stage producing a working deliverable.
Really, what it all comes down to is a tradeoff between forethought and refactoring. The more forethought you put into a project, the less refactoring you have to do after every product release. Obviously, too much forethought, and you'll never actually code anything. Not enough forethought, and you'll have to spend ages refactoring your codebase every time you make a release.
Agile and Waterfall represent two ends of a vast spectrum, with many shades of gray in between. It's up to the developer to decide how much forethought to put into a given project. There's no one-size-fits-all solution, but as any programmer knows, such things do not exist in the world of software development.
Admin
This way I don't have to go to the dentist any more.
Admin
And as for the gentleman who suggested that XP is great because it produces a solid base for the less talented programmers who come along later to maintain it, may I recommend that he look up the 80/20 rule? Why should anyone assume that the original team is any better than the maintenance team?
Admin
Unfortunately, it's the only way to present it to businesses.
Admin
Admin
"If iterative development is the best way to create or improve something, why is the process exempt from the set of somethings? Why can't "iterative development" and "constant refactoring" be used on the process itself?"
When teams take any Agile method seriously, they inspect and adapt iteratively with frequent retrospectives, not just the code but all aspects of the project at hand. Through the experiements and actions they chose during the retrospective, they "constantly refactor" methods, process and teamwork. I have heard several of the Agile thought-leaders say some variation of, "If you aren't holding retrospectives at the end of every iteration, release, and project, you aren't 'doing' Agile." I agree. So the the answer to the question above is...iterative development and constant refactoring ARE used on the process itself.
Admin
It gets better: the first recognizable Egyptian pyramid (the famous step-pyramid of Djoser in Saqqara) was in fact built this way, and in many ways is more analogous to the Agile development method than the more simplistic example given. The pyramid was not originally intended as a pyramid. It started life as a mastaba, a stone edifice with walls slanting slightly inward which terminated in a broad, flat top. Sort of a mesa. But the brilliant architect Imhotep (yes, that Imhotep) got the idea to make it more spectacular and began adding on to it. (This was not driven by a desire to achieve a pyramid even if the pharaoh died prematurely; in fact, Djoser's longevity contributed to the continual improvement of his mastaba.) He built it outwards on two faces, widening the original mastaba, and then built a second, smaller mastaba on top. Then he did this again a few more times until Djoser passed away and had to be interred in the thing. The design was very popular, and subsequent pharaohs also had such edifices constructed, with various architects adding their own innovations until eventually they settled on the clean lines we're accustomed to.
Many other pyramids around the world were also built by building a small pyramid and then expanding it successively. In fact, this was the standard method for building pyramids in most Mesoamerican societies. Those pyramids were not usually intended as tombs for royalty (some were) but rather as temple complexes, and they were expanded progressively over a period of centuries.
Yep. None of the Egyptian pyramids have or require foundations; they are built directly on bedrock.
Actually, it's true -- some of the pyramids are lined up in this way, most notably the Great Pyramid of Khufu (aka Cheops). The Ancient Egyptians were very much aware of astronomy and attributed special significance to the rising and setting of certain stars, mainly for agricultural purposes. (It helped forecast the Nile's annual floods.) It also tied into their beliefs pertaining to the afterlife, where pharaohs were believed to join the sun-god on his Barque of Millions of Years. Aligning the passages correctly was intended to help the pharaoh's spirit navigate (the Egyptians had some very complex ideas about life after death).
However, it is worth noting that the tunnel no longer points at its intended spot in the heavens, but towards another spot. Between the real motion of the stars and the precession of the Earth, the stars are not precisely where they were four thousand years ago.
Admin
Except for his name. That appears to be right.
Admin
To say (and I quote) that "Agile methodologies simply cannot work." is to have presumed that all those who believe that Agile does work, somehow are preaching that "Agile is right for everybody". "Cannot" is an extreme(ly) non-agile pre-presumption - a self fulfilling conclusion of a sense.
As a firm Agile "believer" with success under the belt - I do not, and have never, thought that Agile is for everyone and certainly have never thought that everyone has to use Agile the same way. To presume such, is the antithesis of the definition of Agile itself - that is, to be non-agile.
So, I guess you aren't a hypocrit - because you act (say) consistently with what you believe. But then again, you just don't KNOW what you are talking about when you use such exclusive presumptions.
Admin
The real WTF here is how you consider Atkins to be a "fad diet". It's a real diet that really works, and lazy people who can't be bothered to stick with the diet plan are the main reason for gaining the weight back. Heck, the only thing most people "know" about the Atkins diet is "you can eat all the meat you want". They hear that, the brain shuts off, and they don't learn the rest of what they need to know. I followed the diet and lost about 60 pounds, and kept it off until I left the diet. It's really that simple. Honest. And if I had a buck for each person who thought they knew what the diet was really like but didn't really have a clue, I'd have made some decent cash.