The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Fixed this and the whole house of cards came crashing down in a fiery J.J. Abrams Micheal Bay style ball of flame.
You should have copied and pasted dandy72's correction. He spelt Michael Bay correctly, you didn't.
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
"Which software development methodologies do you use?"
What I think has been lost in all the noise of so-called methodologies is the total disregard for quality. And by that I mean simple things like DRY principle and even correct spelling (particularly customer facing UI's).
We speak of passion for software development, but where is the passion for doing something well? I don't mean perfect, but the code I so often encounter just screams "I clearly don't give a sh*t."
These methodologies, they don't address any of this. Where in these methodologies is "show that you care about your work?" It doesn't exist.
Maybe I should create a Care-Bear[^] Methodology and write a "care meter" plugin for VS.
I don't mean perfect, but the code I so often encounter just screams "I clearly don't give a sh*t."
These methodologies, they don't address any of this.
I believe you may find that the answer is related to what I call : Assembly-Line Programming
Very many devs are writing only one small piece of anything they are building.
This means you churn out your piece and someone else has the whole in mind. You don't care.
It's just like the old Automobile lines. Screw on 3 bolts and let it go down the line. 3 bolts! 3 bolts! 3 bolts! Screw it, I'm tired today, 2 bolts! 2 bolts!!
It is a human condition thing that is difficult to weed out in these large projects. Large projects where you are only one small little piece make you feel like you are accomplishing basically nothing. it's a human problem.
However, those of us who create maybe the entire Software Product from end-to-end and even write the documentation and are completely "responsible" get a totally different experience from it. That's where the real energy comes from.
But, how to do this on a large project!?! I'm not sure.
And often on big projects you attempt to tell someone, "uh, I don't think this is going quite right." And they tell you, "Dont rock the boat, you trouble-maker. Sit down, shut up and get your bolts on!!"
On end-to-end projects, you better get it right. You're the only one and you better rock the boat a lot.
The word I always use to sum all of this up is: Ownership!
This is also what the Agile Manifesto means by :
Agile Manifesto Principle:
The best architectures, requirements, and designs
emerge from self-organizing teams.
It means you go out and find people who are engaged in the process and you "contract" them to build and own a particular piece. This is self-organizing team where each individual cares deeply about what s/he is building and owns it completely.
However, teams are not created this way in BigCorp. They just give you devs or DBAs or whatever to do something (screw on a bolt).
The problem is it that quality is too expensive, and we live in a world where quality software just isn't very important anymore.
So what if there is problems in the software, we can roll out a patch within 24 hours.
It's not like the old days where you have to get it near perfect first time because the cost of a patch was just too expensive.
The most obvious example of this is with video games. It used to be that the game had to work first time and needed testing to death, because nobody wanted the costs of a recall. Whereas today, they ship games before they are even finished and then release a "day one" patch in time for release/delivery day.
In short, there just isn't enough consequence to releasing bugs anymore.