Why don’t software development methodologies work?
typicalprogrammer.com
Why don’t software development methodologies work?
1–10 of 201 posts
Re: Why don’t software development methodologies work?
#2I have to say, I'm not a huge fan of articles or discussions with titles that beg the question.
Re: Why don’t software development methodologies work?
#3this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.
Re: Why don’t software development methodologies work?
#4I absolutely agree that no software development methodology is guaranteed to work. However, there are certain things that one can do to reduce the chances of embarrassing development stalls, such as proper documentation, continuous unit testing, talking to the end user, and team communication.
Re: Why don’t software development methodologies work?
#5Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.
Re: Why don’t software development methodologies work?
#6In my own anecdotal experience I would say the team matters way more than the methodology. I've been on teams that could have been (and were) repeatedly successful on projects that ranged widely from strict agile to strict waterfall. Every single time that team pumped out good quality software reasonably on time.
I've also been on teams that were not successful no matter what methodology they used. The team just wasn't cohesive, didn't have enough talent, and/or had poor leadership.
Re: Why don’t software development methodologies work?
#71. Most important thing: do the users want the change. If not they sabotage and you fail. Users will never be happy.
2. Do you have enough experience and do they work well together, if not your mostly screwed. Right hand doesn't know what the left is doing. Takes too long to train new people usually.
3. Are estimates being treated as estimates or is date,team and scope being dictated from above? project triangle anyone. Stretch goals for managers mean long nights and weekends for the team and bonuses for other companies recruiters.
4. Has management been over sold on buzz words and marketing hype?
5. Is there some kind of incentive to come in under budget. So, much for quality.
All of the above can screw up a project quick.
Re: Why don’t software development methodologies work?
#8this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.
>anti-intellectualism that is so pervasive in the software development scene
Errrr....
Re: Why don’t software development methodologies work?
#9So what this article is really saying (although reluctantly it seems) is that methodologies really do work, it's just not that they're the end-all and be-all. You need to have common vision and communication that works around the team's goals and personalities. Seems to be pretty common sense to me.
Re: Why don’t software development methodologies work?
#10Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.
I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers.
For example, we had coding standards requiring a comment explaining the contract for each method written, and this was enforced by version control on check-in. My colleagues were putting in comments like this:
/**
* Comment
*
* @param foo Parameter
* @param bar Another parameter
* @returns Something
*/