April 5, 2010 at 5:45 pm
CirquedeSQLeil (4/5/2010)
Jeff Moden (4/5/2010)
Tom.Thomson (4/5/2010)
who are prepared to lie about how much testing they have done because they think they will get away with it.Heh... I love it when they do that. Makes them easy to fire when their stuff repeatedly fails even though they've "tested it". 😉
If the code is full of mistakes, what's to say the test plan or testing is free of mistakes?
Maybe they are being honest in making that statement. 😀
... or maybe not. Which ever way it turns out, you can always tell.
On the flip side, my boss used to tell me, "If you never make a mistake, it's because I'm not pushing you hard enough." I take that into consideration with others, as well, but I won't put up with someone lying to me.
--Jeff Moden
April 5, 2010 at 5:48 pm
There is no good reason to put up with persistent lying. I certainly agree there.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
October 14, 2010 at 1:56 pm
j.a.c (2/3/2010)
Why is it that the qualities of paying attention to detail and being thorough are missing from an alarming percentage of developers and DBAs that I work with?
Because they are human beings? Errare humanum est (et confiteri errorem prudentis).
People who don't do the bit in brackets are the ones who get me mad.
Tom
October 14, 2010 at 2:43 pm
A couple of code shops I've been in were nothing but hamburger code. We fixed it only when we heard screams of murder, we pushed out code as fast as possible.. partially because the business had changed so much in one year who the heck cares if it's 5 year expandable, we're rebuilding in 2 years anyway.
You always, though, own up to your mistakes. Took a five nines server down and had 180 ppl sitting around for 4 days one time, but I walked into my boss's office ten minutes after I did it and explained the problem, immediately, and began the fix, immediately. If you can't own up to your responsibility, you shouldn't have it. I'd rather have a bad honest coder then a good one who can't admit being wrong or making a mistake. One I can train, the other I can only shoot.
This problem, though, isn't just prevalent in 'x' industry, but IT wide. Look at how many PC games come out now where 'early buyers' are nothing more then 'extended Beta testers'? Even console games have started getting regular bug fix updates... self-contained code with no external inputs Besides up/down/A/B.
Part of it's the complexity, part of it's the modular design theory, part of it's the SCRUM theory that everyone's in love with. Arbitrary divisions of a waterfall are not SCRUM, they're milestones. If you're pushing things to the edge, you're not reaching arbitrary milestones, you're probably still trying to research the blasted thing. 🙂 So, either you shove "something" out there to keep the scrum team rolling, or you're the bottleneck who failed the sprint. You are almost NEVER given time, even in the next sprint, to go back and fix it. There's too much other stuff to do.
It's hard to be perfect when you're barely able to keep your tires on the road.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 14, 2010 at 3:35 pm
I am in that boat right now. Bad design decisions are made just to make the end of the sprint. Miss too many sprint deadlines and *poof*... there goes your raise. Any minor defects (read technical debt) are put into the backlog. And around here we call the backlog the graveyard, those defects are never seen again.
October 18, 2010 at 11:14 am
Sorry - Wrong Thread....
Joe
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply