tag:blogger.com,1999:blog-8791723.post110073626300389687..comments2023-09-22T11:01:30.370-07:00Comments on Val the C# Gal: Agile Methods vs. the Waterfall MethodValerie Vogthttp://www.blogger.com/profile/14342788492213089415noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-8791723.post-52087165208829714842009-01-19T20:23:00.000-08:002009-01-19T20:23:00.000-08:00I am sorry to hear that you are in an old, stodgy ...I am sorry to hear that you are in an old, stodgy waterfall project. How long are you spending on requirements and design? Will you at least phase development releases?Valerie Vogthttps://www.blogger.com/profile/14342788492213089415noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-31652904160396837952009-01-19T11:23:00.000-08:002009-01-19T11:23:00.000-08:00Currently involved in a fairly large waterfall pro...Currently involved in a fairly large waterfall project with a big old-world client. Actually, the project isn't that large, but requires a tight delivery date, so it's been comical watching the process fall all over itself. Literally, meetings to plan meetings, reams of docs no one will read, and condescension to those of us who suggest an Agile approach. No one believes the dates will be hit, but they are working very hard to make it happen. In the end I think it will, but the massive investment in time and effort is epic. If they had applied half the resources to doing actual work, and pared down the process, it would be done by now, at half the cost.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8791723.post-5586660153120994712008-08-09T05:47:00.000-07:002008-08-09T05:47:00.000-07:00I've been involved in building solutions for many ...I've been involved in building solutions for many years now, during that time one of the key lessons I have learnt is that you need to tailor your approach / method based on the kind of project, client needs, complexity, quality... the list goes on. This could mean you select 'water-fall', agile, or some kind of iterative, prototyping etc...<BR/>It isn't as simple as saying 'we do agile development here' and throw the detailed requirements and design templates out the window.... Some projects I have worked on suit agile techniques - e.g. where there are good subject matter experts available, complex abstract concepts are not involved... etc.<BR/>Other projects require some of the diciplined aspects that agile steers away from.<BR/>You can fail to deliver no matter what method you use...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8791723.post-31812345361212438422008-06-25T19:58:00.000-07:002008-06-25T19:58:00.000-07:00Just curious as to why a CIO of a 2000 worker comp...Just curious as to why a CIO of a 2000 worker company takes the time to troll C# blogs. Anyway, lets take this offshoring thing to it's logical conclusion (cost saving wise) and outsource the entire IT department-CIO included, as I suspect there is someone there who can do that job for 1/3 the cost too. Amazing how once one is invited into the farmhouse (Animal Farm) one can take on a different viewpoint. Meanwhile , back here in the barn...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8791723.post-52157520429827499382008-03-28T22:07:00.000-07:002008-03-28T22:07:00.000-07:00i prefer agile methodsi prefer agile methodschinitaprincessahttps://www.blogger.com/profile/07485858428452827018noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-57507836292619110462007-10-11T12:10:00.000-07:002007-10-11T12:10:00.000-07:00I was talking to a good friend the other day about...I was talking to a good friend the other day about project management styles (scrum vs waterfall), engineering practices (xp, rad, rup, etc), and culture. We were mentioning how agile is becoming more and more 'mainstream' these days because the culture of organizations are more and more accepting of it. <BR/><BR/>I find it also funny that people with years of "experience" claim that there's no significant proof that methodologies have any effect on efficiency. It's entertaining to also hear that 'paired programming' is thought simply as putting two developers on the same task expecting them to put out "twice as much code". That isn't the intent and someone who has any clue about XP would know this.<BR/><BR/>Anyhow, Agile when used correctly isn' tnecissarily more productive, but it IS : more visible, more accountable, and more enjoyable to the developers. These things make it great for a culture that accepts such things.<BR/><BR/>For example, your middle managers who always say "nothing is wrong, everything is going great" have a lot to fear from agile practices, because they cannot hide behind politics and paperwork anymore.<BR/><BR/>laters!James Peckhamhttps://www.blogger.com/profile/07681505580404520676noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-57236764546070849232007-06-12T01:57:00.000-07:002007-06-12T01:57:00.000-07:00By the way I have nothing against outsourcing, how...By the way I have nothing against outsourcing, however it does not absolve responsibility from the client of the outsourcer. The whole process needs to be closely monitored with careful reviews of designs and code.VinnyRhttps://www.blogger.com/profile/15228511784878638060noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-85918344519522729902007-06-12T01:55:00.000-07:002007-06-12T01:55:00.000-07:00Re: Anonymous CIO of 2000 employee firmSo your QA ...Re: Anonymous CIO of 2000 employee firm<BR/><BR/>So your QA department signed of on code because it was functional. Thats great. However your poor knowledge of software development shows when you dismiss the proper use of patterns and elegant code. Yes you managed to get the code out quickly, but it will hit you when you need to make any changes to the code. The aim of using patterns is to have clear maintainable code.<BR/>What is likely to happen if the code is not well designed is that it may take a lot longer to make what would seem to be a trivial change. All because shortcuts were taken at the start.VinnyRhttps://www.blogger.com/profile/15228511784878638060noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1170560675816786802007-02-03T19:44:00.000-08:002007-02-03T19:44:00.000-08:00Waterfall is dead, we all now it but companies are...Waterfall is dead, we all now it but companies are too scared to try anything else unless it is a very small pilot project.<BR/><BR/>Long live Agile.<BR/><BR/> <A HREF="http://thebusinessanalyst.blogspot.com/2007/01/what-vs-how.html" REL="nofollow">What vs How</A>N from snjtechconsulting.com.auhttps://www.blogger.com/profile/13514697281305618703noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100899049731273042004-11-19T13:17:00.000-08:002004-11-19T13:17:00.000-08:00blameMike -
Ah, yes, those evil corporate manage...blameMike - <br /><br />Ah, yes, those evil corporate managers. How dare they get richer!<br /><br />Seriously, why does this bother you? I've never understood why it is a problem for organizations and their corporate management to make decisions based on costs. I mean, we can argue that they are wrong about the costs, that they are not truly evaluating accurately the long-term costs of outsourcing work. But to just say they are just getting "richer" seems to apply a negative value judgment to them that isn't necessarily fair. <br /><br />It never bothers me when other people make more money than me. More power to them. It only bothers me when the government takes away the money that I earned.RGhttps://www.blogger.com/profile/00423015156937218968noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100894820512516802004-11-19T12:07:00.000-08:002004-11-19T12:07:00.000-08:00blameMike-
Why does the topic of off-shore work b...blameMike-<br /><br />Why does the topic of off-shore work bother you so much? Have you been directly affected by this?<br /><br />--ValValerie Vogthttps://www.blogger.com/profile/14342788492213089415noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100883793171710932004-11-19T09:03:00.000-08:002004-11-19T09:03:00.000-08:00Anonymous-
As the author of this blog, I apprecia...Anonymous-<br /><br />As the author of this blog, I appreciate conflicting view points, and I quite enjoyed your comments. <br /><br />I agree with you that scalability and flexibility of a solution are only valuable if it is a requirement of the customer. I wrote a post on Gold-Plating that asked if it is possible that in trying to deliver the most elegant solution, we end up costing our clients money when we are not enhancing their solution in a way that matters to their business.<br /><br />As far as agile methods, I agree that we need to be able to sell management on the value that agile methods will add to projects. I believe the value added lies in the fact that customers will end up with the product they need rather than the product they intially speced out. There may be projects where the intial specification ends up being everything that is needed. In my experience, which I admit is not as lengthy as your experience but I have been around a while, there are key business needs missed in the specs or business needs change between the time the spec is written and the time the product is delivered.<br /><br />I am interested to know more about the project you sent out to India. Was the project complex? How large of a project was it? Even if your QA department gave the application a thumbs up, have you needed the product enhanced or have you come across any parts of the application that are not what you initially intended?<br /><br />--ValValerie Vogthttps://www.blogger.com/profile/14342788492213089415noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100832617309724162004-11-18T18:50:00.000-08:002004-11-18T18:50:00.000-08:00No folks, I am not the point-haired boss of Dilber...No folks, I am not the point-haired boss of Dilbert fame. I am the CIO of a 2000 employee manufacturing firm who has spent an entire career working in all facets of IT including many years as a software developer. <br /><br />Please understand if you folks would prefer not to have opposing viewpoints represented then please pardon my intrusion into what will be little more than your mental-masturbation session as you stroke your egos over how smart you folks are for advocating agile methods to one another. <br /><br />However I hope that my alternative views might be of some help to you folks who appear to be very much like the young people on my staff who turned me on to this blog in the first place.<br /><br />It seems to me that you folks are sort of “singing to the choir” when you ought to be trying to convince people like me that you are right. After all, it is people at my level who in most cases decide whether or not to buy your services or even decide how you are going to work.<br /><br />Let me explain to you why I injected the spectre of foreign outsourcing into your discussion. Earlier this year I made the difficult decision to outsource a very important development effort at my company to a firm based in India. This was a very controversial and potentially disruptive decision. However the business case for making this decision was quite sound and it was being advocated by my boss, our company’s CEO, as well as the VP of the division of our company who will be using the software. <br /><br />Competing with the firm in India was a local IT firm, as well as our own in-house developers. The bottom line was that the firm from India’s project bid was literally 1/3 the cost of the local firm and they guaranteed delivery in about one half the time. Our in-house development staff, who has a back-log of more than three man years could not even come close to meeting the demands of the business unit in question. Both the local firm and my in-house staff are proponents of methodologies such as paired-programming and as part of the bid process they tried to assert that they had a competitive advantage because they were local and would have more intimate contact with the end user and could construct better quality solutions. <br /><br />Over the past couple months we have implemented the solution crafted by the firm from India. During our review of the code, several of my in-house folks argued that the solution developed in India was not very elegant and did not implement various patterns properly. They in essence tried to suggest that we were buying “crappy code”. And yet, the code was certified by our QA group in record time with minimal defects. Likewise our end users are satisfied with the performance and functionality of the solution.<br /><br />Now, do I believe that the code from India is perfect? Nope. Do I think our in-house folks might have been able to write better code? Perhaps. Does it matter? Not much. <br /><br />The software from India was cheap and did what we wanted it to do. Will it scale? Maybe. But then again, a lot of code our in-house folks have written over the years that supposedly would be scalable and reusable turned out to be neither.<br /><br />Now consider my real dilemma: On the one hand I have folks on my staff advocating agile methods which look to be more costly in terms of manpower and possibly developer productivity. On the other hand, I have a happy VP and CEO who are asking me why we should not do more of our development in India where they seem focused on getting the job done in the quickest and most cost effective manner.<br /><br />Folks you can choose to believe that everybody in management are a bunch of cretins who do not appreciate the beauty of your code and the wonderful benefits of your methodologies. But I will tell you that we work very hard to make sound business decisions that are good for our company and our bottom line; both in the short term and the long term. <br /><br />All of us hate the notion of outsourcing to India. We like our in-house programming staff. They are our friends and neighbors. But we will hold our nose and make the best business decision. <br /><br />So I strongly recommend that when you advocate for agile methods you make certain to make your case in terms measurable speed of delivery, value to customer, and lower costs. Because in the end, flowery declarations about more elegant code and singing “kum-bah-yah” with end users is not going to carry the day.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100793524713189732004-11-18T07:58:00.000-08:002004-11-18T07:58:00.000-08:00Hey Val...
Here are a couple of thoughts from som...Hey Val...<br /><br />Here are a couple of thoughts from someone who manages and has managed software developers for many years. <br /><br />You know this "Agile Methods" stuff is hardly new. Discussions about group programming efforts, iterative development, and end user involvement from the get-go were prevalent back in the mainframe days before you were born. We just did not have sexy names for it.<br /><br />I can tell you from experience in the real world, not just in the rarified air of academic computing departments and consulting firms that I can find programmers who work well using “agile methods” as well as developers who do not. I can also cite projects after project that was successful using such methodologies as well as projects that literally crashed and burned. <br /><br />But the truth is that I can not think of single project that I can say was successful or a failure BECAUSE of the methodology that was used. And by the way, most customers (you know the folks who really pay your salary) don’t give a damn about this methodology crap. In fact, they get bored and annoyed very quickly with it. <br /><br />Even worse many customers I am familiar with are highly skeptical of “paired programming” and lots of group activities. They are concerned that in many instances such processes are simply excuses to charge them more for less productivity.<br /><br />In the end, I think all of you ought to be less concerned about the methodology you are using and more concerned about the value you are delivering. <br /><br />Or put another way, do you think your REAL COMPETITION (the folks coding in New Delhi, Kuala Lumpur, and Bangalore) are spending their time posting on blogs about methodologies? Do you think they engage in hand-wringing exercises complaining about how much people with or without degrees are being paid while they are being twice as productive writing just good-enough code for 30% of what you are being paid?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100756711366080312004-11-17T21:45:00.000-08:002004-11-17T21:45:00.000-08:00How awful for you that you had to work with such n...How awful for you that you had to work with such negative co-workers with their large egos and bad attitudes about the glories of agile methods! My goodness, how could you stand such blowhards?!<br /><br />;)<br /><br />Seriously, though...with regard to paired programming, can I make an observation? In general, I've noticed that you are a fairly positive person who likes most people. I won't pretend to speak for everyone, but some more seasoned developers like myself have worked on too many projects with people that we frankly didn't like very much. Perhaps we didn't care for their programming approach. Perhaps they had a personal mannerism or two that we found annoying (like speaking very, very slowly and not saying anything useful). Or perhaps their personal hygiene left something to be desired. At any rate, we know and understand that if paired programming becomes the norm, sooner or later we'll be paired up with these yutzes. And that is a price that is just too high to pay. Ick.<br /><br />Stop the madness.RGhttps://www.blogger.com/profile/00423015156937218968noreply@blogger.comtag:blogger.com,1999:blog-8791723.post-1100738378962684182004-11-17T16:39:00.000-08:002004-11-17T16:39:00.000-08:00Amen, sister!Amen, sister!Anonymousnoreply@blogger.com