|
That's pretty much my experience too. I've used refactoring techniques for as long as I can remember - although for a while I just called it "re-writing" which scared my then managers no end. 
I know what you mean about terminology, but I suspect that no matter what terminology you use people who follow it blindly will make life harder for those who are more considered about changing the way things are done.
Still, having sat through some of the Agile and Lean sessions at ACCU over the last couple of years I'm much convinced this is the way to go. Shame we can't get more managers in front of the presenters who really know their stuff, really.
|
|
|
|
|
Anna-Jayne Metcalfe wrote: Shame we can't get more managers in front of the presenters who really know their stuff, really
Agree.
My opinion on all these methodology choices was and is that good managers and teams do not follow any - each project (combination of people, technology, business cases) is unique, and experience should tell people what is required for its success. It would normally be some combination of ideas - but in my books, purely following some methodology is for clueless: it looks like a chief who's reading a cookbook when preparing a meal.
|
|
|
|
|
I couldn't have put it better myself. 
Individuals (developers or managers) who jump on a particular process as "the way to do it" are often also those who refuse to even attempt to improve either their skills or the way they or their teams work. They just want an easylife, and for someone else to take responsibility.
Unfortunately, there are far too many lemmings in the software industry.
|
|
|
|
|
Although I prefer concepts from the Iterative camp, I must agree that following blindly creates problems and can stifle creativity. To quote Barbossa from Pirates of The Caribbean the code is more like guidelines. The methodologies are like tools, use what works for your project, group, and customers.
Mike Marcus
|
|
|
|
|
The problem inherent to this design concept is that it relies on the complete understanding of the end users needs by a single person (it is even worse when a committee does the design) who then designs it all. It then takes a LONG time to discover that the designer misunderstood what the end user wanted.
Result = failure of concept followed by redesign and so add infinitum.
|
|
|
|
|
Definitely. I've lost count of the number of times I've agitated for direct contact with end users during my career.
In the end I took a different tack and started arguing the users' perspective against the company. Although a very risky thing to do, it actually paid off in a big way.
|
|
|
|
|
The reason is simple.
You can easily know what is happening in a project. The majority of people on this site are probably far above the standard developer, knowing that there _are_ choices in the matter.
In many companies you still have to fight with people not even posessing the basic knowledge.
So how do you keep track of these people? You waterfall your projects, because then you have experienced people doing the Big Upfront Design and then less experienced people do the coding.
Now that being said, _only_ using 1 waterfall for a project is a majorly bad idea. One has to combine it with atleast some iterative splitups.
Our experience has shown us that waterfall combined with projects no bigger than 4 weeks of fulltime work for 1 developer works rather well.
|
|
|
|
|
That's probably because the problem is simple enough and well defined. You can then design a solution and pass it down to the junior stuff to code up. More complex / not so easily defined problems tend to break down, because as others have pointed out, the designer might misunderstand the needs of the users and/or those needs might change.
In this case the open source philosophy of releasing often tends to perform better because it can adapt better to the ever changing requirements.
|
|
|
|
|
If you're using iterations, I'd sucggest that isn't Waterfall - it's something that works for you instead.
True Waterfall development requires you to do all of the design up front. Then the coding, integration and testing - in that order. When you look at it in that way, it's kinda doomed for all but the smallest projects.
|
|
|
|
|
Anna-Jayne Metcalfe wrote: True Waterfall development requires you to do all of the design up front.
No one does true waterfall any longer. Even the most staid processes have given way to a form of iteration. I work in an FDA-regulated industry, and the documentation for software is mandatory. Sign-offs are required for requirements, design, configuration, functional testing, user testing, and installation verifications. In addition, there is a document index, a traceability document for requirements, a development summary, and a release notice. That's ten sets of signatures to go from start to finish. SETS, meaning I could have fifty signatures by the end.
Now, what do you imagine happens when a requirements document is signed, you're well into design, and you determine with absolute certainty that one of the requirements is wrong? Just so you know, getting signatures is not electronic, so it could five days to get a document reviewed and approved again, at minimum.
Here's what you do: you PUBLISH requirements for review, you do not make them mandatory to progress to design. You do as many discovery missions as you can, right up to the point at which you have some working prototypes in a sandbox somewhere. You route requirements for signature only after design has been largely scoped and defined, and working prototypes exist for all major components. You do this for design and configuration only after you've unit tested almost all of your code. And so forth...
It still looks like a waterfall from the CIO's perspective, but on the ground, we're running spirals and iterations, blowing up prototypes, and chasing down loose ends and ambiguity right until we emerge from QA testing.
So, do I do waterfall development?
--#
|
|
|
|
|
"Waterfall" was a stupid analogy, people have always done some form of iteration.
Maybe you'd be carrying the water back up the waterfall in buckets or something...
Agile methods can hide cowboy coders, "waterfall" needs proper management in case the requirements/design need changing.
"Waterfall" is popular because in business people need to know what they're getting, how long it'll take and how much it'll cost.
We effectively have a contract with customers once the requirements are signed off and we've agreed the money they'll be charged.
We can't start work until we're sure it's going to be paid for.
This contract of signed off requirements protects you. If it does turn out the desired solution is more than what was agreed and will take twice as long you can ask for twice as much money, not have the customer still want you to do it for the original amount.
I've often found the problem to be the requirements not being signed off in time and developers having no approved work to do.
This leads to them hacking code.
When a developer has finished a project, the next one should be signed off and ready to go.
I think it's stupid not to do the maximum possible requirements/design work up front whatever the philosophy.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)