- 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
I fully agree that a good process won't help to get success when the developers are not good enough, but the other is also true.
Having braindead processes will hinder good developers, and you have the warranty that the project won't succeed.
Admin
I see a lot of people bashing this article because they think that it bashed Agile Development. I did not get the impression that it was bashing Agile, but maybe I'm missing something.
I think that the article says this: people think that they need this thing called "Agile" and they then adopt a new process. However, there are still people in the team who are not educated in Agile techniques. This is actually un-Agile, because Agile favours people over process.
I found myself in a job where Agile was used as a marketing term to prospective clients. What I found there was that Agile meant no documentation and no process. Again, this is not Agile -- clearly there were people there who knew about this term "Agile", but did not know how it worked.
Admin
The analogy used, like most between software and building, does not work well.
Software is complex. Change is endemic. Therefore the process employed needs to be appropriate. This turns out to be a system with a feedback loop and a short cycle time. It allows stakeholders and the development team to work inspect small increments of built software and adapt as they understand more and as the environment changes around them.
It's true that bad developers will deliver crp software. This will be true for every process. With a transparent, agile process you will get the bad news soon and you can then do something about it. With waterfall you'll pss bucketloads of money into the project before you find out it's doomed.
Perhaps the lesson for agile evangelists is to stop using the same old, bad analogies.
Peter
Admin
Re: ...and the overwhelming majority of software developers (i.e. the less-than-good folks), Agile methodologies simply cannot work
One of the Agile methodologies requirements is to have less but better developers.
Admin
Agile is actually pragmatic. Instead of playing games and pretending we are going to be able to get everything right the first time and forever after in one or two iterations, with full documentation (that of course will never become obsolete)....we accept the reality that the path to hell is paved with good intentions. Build what you need now, extend it as it is used because after your first release (no matter how thoroughly planned) users will want to add to it and/or change it and/or will have decided they didn't actually need it and/or will now see what the planning was all about and now want to introduce the actual features they needed. Create as much documentation as you need now, instead of a bunch of diagrams that will become obsolete nearly immediately. Test driven by the way is a design methodology, not a testing methodology. BTW I love the criticism that Agile doesn't produce enough documentation -- ask the person who offers that up how much documentation they produce with the methodology they prefer and the answer is usually little to none.
Admin
I started off being pretty jazzed about this post, but the farther I've gotten into it, the more disappointed I've grown.
Alex, you're asserting that Agile(like) development methodologies are "defective" because they only work for good programmers.
Either you think that the use of some kind - pick one - of methodology helps, or you don't. But, your paean to better education and quality control in the corps of developers out there aside, you can't seriously mean that these methodologies are "defective" just because it can't help bad coders.
By that logic, an F-22 is defective because I can't fly one, and a Ferrari Enzo is defective because the proprietors of shady game companies wrap them around utility poles.
Admin
As other people have pointed out, I stopped reading when I reached the idea of a pyramid with a square base. This is indeed a WTF, but probably not in the way that the author meant it. I suggest enrolling in an Agile programming class involving cubical blocks of concrete, the whips of overseers, and associated UFOs.
Admin
Very good point, but... Really good developers are extremely difficult to find. In my company there are around 200 software developers, 6 or 7 architects, 10 managers/team leads, and i know around 60 of them. Now how many of them are good? None. Well there used to be one, but he stayed for less than 1 month then quit.
From my experience (with a total of 6 employers), i can only remember one company who had a handful of really good people.
Birds of a feather flock together.
So what about me? I am NOT a good developer, but i know where i need to improve and am working hard at it. The only reason i'm staying in my current job is that it allows me to experiment with lots of stuff i want to learn. The sad thing is that not a single person around me could see the light.
Admin
It's all about design. If you have people who can do it, then up-front design is obviously the right thing to do. Good up-front designs do not remove flexibility and responsiveness, they actually improve it due to greater understanding of the problem domain.
If you can't do design, then choosing between agile or waterfall is like choosing whether to barf in the sink or the bath - either way you'll end up with a mess to clean up and a bitter taste in your mouth.
Software people who can't do design like to hide that fact so they advocate methodologies that provide impressive looking results early on and then paint over the cracks that show up later using religious sounding dogma.
PS captcha is "stinky". How appropriate. Put those Kent Beck books back on the shelf and start learning engineering, people!
Admin
True, you do need good developers to write good code, and that's a key point, but what about everyone else you need to build a successful system, like testers, prodcut analysts and customers? Everyone seems hung up on developers. What are you going to build without input and how many of us have written code that works and integrates without rework. I'm not hung up on agile, I've seen it work and fail, but I am hung up on teams and eliminating waste in development efforts and that seems to be missing in the thread
Admin
I hope you're kidding. I'd like to see more talk 'about what needs to get done' and less code until you understand what you're doing. I think we have a few too many lines(*1000000) of unused or complex code floating around out there.
Admin
I thought you would enjoy a paper I wrote and presented at several conferences.
Agile Methods and Other Fairy Tales
The link is http://www.SoftwareMetrics.Com/Agile
http://www.SoftwareMetrics.Com/Agile
David Longstreet Software Economist www.SoftwareMetrics.Com
Admin
We tried agile at a game company, and it bombed. Talk about tying up the hands of the superstar programmers, bogging them down in meetings, having them code to be ready for presentation instead of for customers. BLEH!
It bombed big time... Mostly due to some people that couldn't stand others not doing things their way and trying to dominate the desgins and meetings. People just ended up with argument fatigue and gave in until they found another job to go to.
Admin
First and foremost, it is possible to build a square pyramid sideways. Adding to two faces would add to its nice, square base.
Admin
When I was an architect, many years ago, I built software based control systems and simulators for power plants. The systems would be installed during an outage, and if the startup of the plant was delayed, penalties ran about 1 million dollars per day. Needless to say the systems were in and up on time.
What I have seen that causes failures (major overruns or cancellations) in big systems of all kinds is a lack of engineering knowledge. That is, the management of teams, the engineering of complex systems, the writing of unambiguous, correct and complete specifications, these are things that are neglected in university and consequently not understood by the computer science and other technical staff suddenly thrust into management positions.
Furthermore, understanding how to successfully build large/and or complex software based systems is learned by OJT, not be reading a book or spending a week getting a certificate. If you have never apprenticed at a senior level on a large successful project then your chances of succeeding in a senior management position of such a project are drastically reduced (near zero). While no one would expect an architect to read a book on bridge building and then manage the construction of a large bridge over a river, in the wonderful world of software, such assumptions are commonplace, e.g. i read Booch's book, so I am all set to build a big OO system.
I see agile as grasping at straws. That is, it is the placing of the seal of approval on a fudge, a grasping at straws.
Yes, agile will work, where the final product is very, very malleable and the staff is small, e.g. people sitting in a room talking to each other. Other than that, agile cannot work by definition. A software architecture is a complex thing, as the amount of code that is written goes up linearly, the effort to refactor goes up exponentially. That is, unfortunately, the way it is.
The only thing to date that has saved agile from a really, really bad reputation is the fact that the good lives on, and the bad (and believe me there is a lot of it) is buried with the accounting losses.
And that, ladies and gentlemen, is just my opinion.
Admin
Alex, No analogy is perfect. The pyramid analogy is a useful tool for convincing people that conventional Waterfall methodologies are particularly problematic. Agile is an interesting alternative, all the same it's not specifically mentioned in Mayo-Smith's Information Week article.
Admin
wow this is guy....screw this shit!
Admin
Mayo-Smith's article doesn't mention Agile and predates the Agile fad by several years.
Admin
Agile is good for understanding requirements and assist the customers to understand their own requirements. Agile can not help your programming and design skills. You have to be good first at programming and design, then you might be able to get benefits from agile practices.
Admin
Loved the message, but this part is just plain wrong: "the only way to lose weight is to eat less and exercise more."
The reality is that 'modern' food makes the vast majority of us fat (I know, I used to be in that majority). Now that I'm back to fresh fruits & veggies & home-cooked meat, I'm in the minority again.
Exercise is good of course, but if you're using it to maintain a healthy body weight, then see the above paragraph. I'm finally slim again, and haven't raised my heart rate above 100 bpm in probably 2 years.
Admin
Good people can't always produce good code: as thedailywtf articles repeatedly show, there are many ways to impede good development. I think that the benefit and challenge of Agile is in removing as many of the impedences as possible while keeping the project focused.
Admin
Agile has a Project Management Plan. They just don't want to write it down.
Agile has a Commumication Plan. They just don't want to write it down.
Agile has an HR Management Plan. They just don't want to write it down.
Agile has a Time Management Plan (Schedule). They just don't want to write it down.
Agile has a Scope Management Plan. (although different). They just don't want to write it down.
Agile has a Budget (Cost) Management Plan. They just don't want to write it down.
Do you get my drift? What is the common thread? Although they don't want to admit it, they do everything a Project Manager should do, they just don't want to write it down.
Admin
I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?
Thanks,
Alex Glaros
Admin
I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?
Here’s the link: http://gov-ideas.com/enterprise_focused_development.htm
Thanks,
Alex Glaros
Admin
It does occur to you that that would be specifying something that is apparently unachievable with the technology in question (ie, unmortared stone)
Admin
No, JamesKilton is correct.
It does work, but what he's saying (and I agree with) is that it's "a state of mind" or rather a way of thinking about and implementing the software you are tasked with.
Like most of us I've used several "methodologies" and as much "hacking" as anyone. but taken as a concept on how to write good code, Agile can help. The key however is getting the point of it rather than following some "agile bible" and that takes good people.
However, inexperienced people can improve if they have good people around to follow (true of anything and any method) and can do it quickly using agile ideas.
So far, I've been at many companies who claim they are "agile" but are no where close (somebody mentioned that sort of thing earlier) and in all cases it was because they just didn't get it... notice that I didn't say they were not good developers, just that they didn't get Agile; for those people and for those in this forum who don't get it (no shame on you), there is little point in trying to force yourself into the cold-press to conform... what your doing might be working for you, so keep your customers happy and keep doing it.
However, this is really all useless bunk anyway if we remember that most of the cost of a product is maintenance, the argument is only about ~20% of the cost.
We that understand Agile, will use it to keep our customers happy, as you will your own system.
Admin
This is single handedly the worst methodology I've ever come across in all 10 years in IT consulting - especially on the large projects. Because where there are large projects, there are politics (I don't make the rules). This model acutally presumes it it can eliminate politics to produce results - and it does quite the opposite. Agile probably would works well for start-ups, but where there are large projects, there will be politics. This is a natural manifestation when there is a combination of expectation and dependence within a project. I work on an Agile project for a Fourtune 100 company, and will be leaving the project and possibly my job because of this crap practice. Just a trash fad which has made me hate going into work every day.
Admin
Agile is an often mis-applied methodology, and it seems everyone wants to bash it because it doesn't work. It does work, but it's rarely done properly.
It's not easy, and it's not a panacea. It doesn't preach 'no documentation' or delivery without planning. On documentation, it recommends that you produce enough (but no more). Same with planning. The key word is enough. If you don't have enough, you fail. You fail not because you chose a bad methodology, but because you took a simple methodology, cherry picked the easy bits and ignored the difficult parts.
Agile is simple, but not easy.
A better analogy might be power tools. An electric jig saw might make cutting easier, but if you're a crap carpenter it just means you screw up quicker (or lose more fingers).
Admin
I wonder if you've become a Scrum master yet? I enjoy reading these types of articles. Damon Poole at Accurev was a Waterfallian as well and is now an Agile proponent. You should have a chat with that guy.
http://www.accurev.com
~M
Admin
Agile is good for understanding requirements and assist the customers to understand their own requirements
The above is not true at all! On eof the principle of Agile is to make the story requirements vague and ambiguos so that open to the discusions.
Admin
Admin
Coding priests should give up on agile and turn to improving stamina and spell damage.
Admin
Re "evolutionary" software: the one thing evolution has in it's favour is TIME - and LOTS of it!
I believe you need to "bootstrap" evolution by having a fair degree of understanding of the customer's requirements early on (and by "fair degree of understanding" I do not necessarily mean 100%, but 80+).
One can't keep on breaking down and re-starting (re-trying?) every time you find out something new from the customer.
That's like evolution-by-failure: "something" will eventually result from all the retry-and-mishap-cycles... even if it takes a few million years...
Ans that is what software development seems to be suffering from.
Admin
So you're saying most developers now are a bunch of sloppy H1 B's who can't write code, say isn't so ! I guess you get what you pay for !
Admin
"Good people can build good software, no matter what methodology they use."
A+
I was lately turned down for a Sr Jave dev role. Although the manager told the recruiter he wanted to hire me, later his dickhead weenie tech bully nixed it, ostensibly because I was "uncomfortable" with agile dev. Doesn't matter that the manager had previously told me they are working toward agility, but have a long way to go.
Admin
I was a developer for 10 years and hated process and management and people who didn't know anything running things.
The next 20 years I was a QA Director and I Was the guy doing the stuff I hated back then.
My conclusions after 30 years in the business and doing it both ways:
Small internal projects can be done fast and well with really good people and little process. Sometimes it gets screwed up. But it's usually small, didn't do too much damage (hopefully), and can usually be fixed fast.
But Murphy's law was created for Big Projects. Documentation (that useless stuff that tells you exactly what a system is supposed to do, how exactly it will be designed and tested) is GREAT (and cumbersome) on big complex stuff because everyone (painstakingly) knows what the hell they are doing and what to expect. And yes it takes MUCH MUCH longer and is a lot of paperwork.
Theory 1: I think there is another reason for Agile: to get rid of dumb, bossy managers. Who needs them making everyone's life miserable, calling meetings all the time, tracking stuff they don't even understand, and they can't even code themselves because everything has changed and they only know stupid COBOL! OK. OK. Well get rid of them and see what happens. I heard stuff like, "its supposed to work that way! That's the way the code was written", or "the true documentation is the code!" (but a) who else can read code but the developer and b) what if it was coded incorrectly?)
Theory 2: I think American culture consists of cowboys roping calves-rugged individualism stuff - "Look what I did!" Asian culture (e.g., Toyota)seems to me to be suited to working together closely as a GROUP. So we Americans have to, (for God's sake!,) change our mindsets, I think, to work in a group setting. That's why things seem to creep back to non Agile all the time, in my opinion, and why there is so much resistance to Agile. Should we go against our DNA? -or find ways to work with it instead? (Personally I'd rather row my boat downstream as opposed to upstream).
What I think is good about Agile:
What I think is needed for Agile to work- -exact requirements -exact test case documents -test EVERYTHING built, -no late deliveries of code since it could break a lot of stuff already tested -and after the last code is written test it again for anything even possibly suspected of being broken by a change.
Well, this goes against most of Agile!
WHY do I suggest this? Because users of software hate bugs-it screws them up royally- clobbers their files sometimes, stops them dead sometimes, requires them to get on the phone to figure out what to do. They also hate stuff that takes a long time to deliver, too. But I've seen more user infuriation and rework with bugs. We had to work around the clock looking for workarounds, finding and fixing bugs, and praying the fix didn't break something else. Who want's that? How do YOU like it if you download something and it blows up??
WARNING: After putting detailed, long processes in place you get award meetings and plaques when the 1st couple releases finally go out flawlessly, then people don't see bugs anymore, then think you can cut down on the processes since we don't have bugs anymore!!, and go back to crap releases again with new management installed to get it out fast (like it should!), then turn on you and blame you when it reverts to buggy (You didn't test it!!). Advice here: don't bother unless you get great management commitment to quality and the process you decide on (whatever it is: Agile, WaterFall or Water-Agile-Fall) - put it into a Quality Policy signed by the President if possible, and put it on the main hallway wall. Get signoff on a documented process too by him or her.
TIP: Management loves documented process so they have understanding of how things are done in their organization (and can modify something if they like): lots of brownie points for this!
Good luck whatever you decide.