|
a.k.a., "You're not going to need it."
I let the usage cases dictate the patterns I use, and try not to make the patterns fit the use cases. It's easier to get things done when you focus on the task and avoid overengineering the problem.
|
|
|
|
|
|
And it works great.
Example: If it doesn't work 6 years later, on a Quad Box 16GB RAM box, then it must be crap, so rewind to:
http://forums.devx.com/showthread.php?t=57395
Someone do a survey what technology and performance areas MS should fix apart from producing junk and dreadful slow 'advances'.
If you say WPF, then go get a 128-core 98315.5Ghz box to move a window, or refresh the screen..
|
|
|
|
|
Questions about code methods always make me smile. After working for 40 years (in aerospace embedded real-time software) for many organizations, my experience has been most organizations don't follow any methodology. What they do is hack the code until they run out of money or time and then update the documents to make it look like they followed the corporate methodology. But I have run across rare organizations who follow some good engineering disciplines. I don't believe they are the norm.
The best situation I have seen is to have a small staff of software engineers who have a deep understanding of the problem domain. Without that, none of the methods seem to work very well.
Ron Ray Miller
|
|
|
|
|
tru dat!! 
void izmoto(char* szKwazi);
|
|
|
|
|
|
Haha I love Dilbert!
Mark Brock
"We're definitely not going to make a G or a PG version of this. It's not PillowfightCraft." -- Chris Metzen
Click here to view my blog
|
|
|
|
|
I must admit the Waterfall philosophy is good. Its simple, when printed it shows where you are, where you should be. Its easy for the management to know what the status of a project is. Even the other techniques use Waterfall (possibly in small amounts). Its also provides the manager (my boss) a tool to hit me on the head when I passed a deadline.
The management doesn't care why I'm behind schedule, its probably my fault anyway (I've should have followed the original plan).
I myself try to Scrum with my colleague and I try to use Agile & Extreme Programming. Then I'm using some kind of Dark and sinister method to translate the progress into his waterfall schema, which drives him completely nuts, since all items are now in progress, even those that are scheduled to start some time in the future.
Learn from the mistakes of others, you may not live long enough to make them all yourself.
|
|
|
|
|
Try loaning him a copy of Managing Humans[^]. By the sound of it, he needs it...
|
|
|
|
|
1 - Planned Obsolescence
2 = Take The Money and Run
These are both models derived from MBA programs the world over.
.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Got some more we sometimes talk about at work:
3 - Fast and pragmatic
4 - Dynamic planning/Dynamic deadlines
|
|
|
|
|
WillemM wrote: 4 - Dynamic planning/Dynamic deadlines
By far, my favorite one!
If you can play The Dance of Eternity (Dream Theater), then we shall make a band.
|
|
|
|
|
You should try PSP/TSP. Mmmm, all the red tape you can eat, plus more.
|
|
|
|
|
*Brings out the garlic* Dude you're evil!
I've used these methods at the university, but its not something I would recommend to any company. This is mainly because it isn't a software development methodology, but a team management methodology.
I'm tempted to call it the quick-and-dirty method as far as actually building software.
|
|
|
|
|
Its been touted as the "Silver Bullet" that's supposed to end all our Development woes and bring projects in on time. Personally, I haven't seen that when I use it. I suspect the same is true for the rest of the teams.
I could go on, but I'd have to book my time spent writing this reply into my project somewhere, lol.
|
|
|
|
|
The weird thing is that there aren't many articles on TSP around.
In fact I couldn't find a single one on google, except for book reviews.
My experience with TSP is rather bad, it simply didn't provide what the team expected and we didn't succesfully complete the project.
When I stopped using TSP and took a serious shot at RUP I finished the product in time with the expected quality. A much more satisfying experience I can tell you that.
I am wondering what other teams have used TSP and what experience they have had with it.
|
|
|
|
|
I agree, that would be interesting to see if there are any "Genuine" reports of it being used for Real life projects. I have no love for it that's for sure.
To my mind a lot of the concepts are antiquated now, I mean, not compiling your code until you've checked it for errors? A compiler combined with Intellisense is easily the best way to ensure your code is syntactically correct.
|
|
|
|
|
Member 4593559 wrote: I mean, not compiling your code until you've checked it for errors?
That's a really bad practice in my mind. It aggrevates the hell out of developers, mainly because we all make mistakes and the compiler makes finding these mistakes really easy. Having a co-worker point out those errors can be a really painful experience. Also it makes building software more expensive, as people have to wait for their work to be checked by someone before they can continue. No matter how well you plan, it will make your work take longer.
At least I am really glad we do code reviews after the developer compiles his work. It may sound bad, but we don't do codereviews on some work as not all code has a significant impact on the quality of the overall product. I think that sometimes you need that pragmatic look at developing software as much as you need to be critical about your work.
|
|
|
|
|
Every time I've encountered a project being developed using BDUF[^] (Big Design Up Front) or Waterfall [^] it has run into big problems sooner or later. It is clearly not the way to do it.
Discuss... 
modified on Monday, September 15, 2008 4:26 AM
|
|
|
|
|
It must be a Monday morning thing - it took me at least 2 minutes to realise the Waterfall2006 site was a wind up. My personal favorite - 'Fit Testing In When You Can; Otherwise Skip It' by Ward Cunningham. Brilliant.
|
|
|
|
|
LOL it is rather good isn't it?
My personal favourite is the note that "Because it's possible you may want to attend all sessions, Waterfall 2006 features no concurrent sessions. All sessions are run sequentially for your enjoyment. However, since in a waterfall process we don't want testers to know anything about coding, or programmers to know anything about design, and so on, you can only attend sessions that match your job function. When you register to attend you'll be asked to select an appropriate job function. When sessions that are not relevant to you are running you will be required to sit idle in the lobby.".
Then again there is http://www.waterfall2006.com/coldewey.html[^]:
"In today's software development projects still up to 50% of the staff still do coding and other productive work. This means that they are completely under-administrated, there are no resources left for controlling, anti-corruption, political correctness, gender-specific subjects and so on. Careful consideration of all these issues will immediately lead to ten times the employees in every software project. This would solve unemployment in all western countries at once without any manager having to invest only a single second into creative thinking."
That's a topic for the Soapbox if ever I saw one. 
|
|
|
|
|
Most of my career(30 + years)in software development has used waterfall. Is it any wonder that only 2 projects in all that time actually made it into production? They only made it because I was able to sneak in some iterative techniques etc. I love the full employment concept though. By the way in case you wondering the group I work with here at Cornell U. Is going SCRUM.
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin
Buddha Dave
|
|
|
|
|
I think I've been lucky - I've never actually been on a project which has completely failed. Nevertheless, I have seen massive overruns, stability problems and the rest. Most of these could however have been avoided by choosing a better development process (and re-educating everyone concerned to design for quality and stability without over-engineering).
I still however cringe when I see most company's idea of a "project plan", though.
Good luck with Scrum!
|
|
|
|
|
It is a tough situation. Waterfall techniques can get bogged down in documentation and Agile is frequently twisted in to a hacker's paradise - neither yielding results for the business.
I've been using some of the "Agile" methods before they even coined the term waterfall. Having multiple, internal milestones and frequent builds helped us to avoid the up front design time sink and the back end integration nightmare of nothing working together.
Unfortunately, there are almost no managers who understand anything other than waterfall.
I also have a problem with the terminology and propaganda around XP and Agile. The terms are intentionally named to make the alternative sound worse. There is the implication that any alternative is wrong.
Nothing is absolute. Use common sense and always work on continuous improvement. This will lead to the best solutions for your environment.
Dale Thompson
|
|
|
|
|
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.
|
|
|
|
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)
