September 28, 2010 at 9:36 am
CirquedeSQLeil (9/28/2010)
Alvin Ramard (9/28/2010)
Jeff Moden (9/28/2010)
It's disappointing, for sure but... you still got paid and they didn't blame you so probably not such a bad gig, eh?Jeff, you trying to speak Canadianese, eh? 😛
Glad to see you're trying to improve yourself. 😀
Speaking of Canada - shouldn't the country be pronounced Canad - eh?
I think it probably was pronounced that way at some point, but it was too hard to sing in the national anthem so they simplified a bit - eh?
That joke is getting old. It's actually C - eh - N - eh - D - eh 😎
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
September 28, 2010 at 10:23 am
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
Think it's a mixture of a few things.
We typically underestimate complexity
We're bad at handling complexity
We're bad at estimating, and often the estimates are made by people who don't have the information required to even begin to do a reasonable estimate.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 28, 2010 at 1:08 pm
Alvin Ramard (9/28/2010)
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
probably both, but we definitely suck at estimating, especially when the scope keeps changing.
Edit: typing not in sync with thinking.
And when the requirements are firm, they many times cut your estimate in time and $.
Greg E
September 28, 2010 at 2:29 pm
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
d) none of the above
I think the root cause is a lack of communication. Just think about it:
If you're a developer: How often did you have a chance to talk to the customer/client (= end user!!) directly in a meeting or workshop to verify what they were really looking for?
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?
I've made the experience if you get the end users and the dev team together with a moderator (= translator for business requirements into software capabilities and vice versa = project manager?) at certain stages of a project it will be well worth the money. Even if it takes a day or two without coding for a few developer, it'll pay off.
Yes, I've done a few projects like that. All finished on time, within budget and with happy end users. And none of the projects ended with exactly what was specified at the beginning. Sometimes it was more, sometimes less but always something different.
September 28, 2010 at 3:08 pm
LutzM (9/28/2010)
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
d) none of the above
I think the root cause is a lack of communication. Just think about it:
If you're a developer: How often did you have a chance to talk to the customer/client (= end user!!) directly in a meeting or workshop to verify what they were really looking for?
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?
I've made the experience if you get the end users and the dev team together with a moderator (= translator for business requirements into software capabilities and vice versa = project manager?) at certain stages of a project it will be well worth the money. Even if it takes a day or two without coding for a few developer, it'll pay off.
Yes, I've done a few projects like that. All finished on time, within budget and with happy end users. And none of the projects ended with exactly what was specified at the beginning. Sometimes it was more, sometimes less but always something different.
That's called a Business Analyst. They work to get the job done right, PM works to get it done on time, leaves the rest of us just working. Beautiful thing when it works.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 28, 2010 at 3:20 pm
SSMS 2008 - Multiple Server query question.
When I open up a normal query window connected to just one server, I can drag a file onto it, and a new window will open up connected to that server/database.
When I open up a query window connected to multiple servers (Registered Servers - right click on a group, select "New Query"), when I drag a file onto it, a new query window opens up, but it is not connected to any of the servers. Is there a way to accomplish this, short of opening up the file and performing a cut/paste into the Multiple Server query window?
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
September 28, 2010 at 3:44 pm
GilaMonster (9/28/2010)
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
Think it's a mixture of a few things.
We typically underestimate complexity
We're bad at handling complexity
We're bad at estimating, and often the estimates are made by people who don't have the information required to even begin to do a reasonable estimate.
I would add to this that things like scope creep and changing requirements add to the problem.
---------------------------------------------------------------------
Use Full Links:
KB Article from Microsoft on how to ask a question on a Forum
September 28, 2010 at 4:04 pm
LutzM (9/28/2010)
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?
I've had this happen before, and it still hasn't worked. Often it seems like you still have customers that don't really know what they want, or how things will change with a new system.
I've heard people talk about not having requirements, but it seems that in many domains, you don't really know what you want until you get something and can think about what to change.
September 28, 2010 at 4:21 pm
Steve Jones - Editor (9/28/2010)
LutzM (9/28/2010)
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?I've had this happen before, and it still hasn't worked. Often it seems like you still have customers that don't really know what they want, or how things will change with a new system.
I've heard people talk about not having requirements, but it seems that in many domains, you don't really know what you want until you get something and can think about what to change.
I see your point. But I don't think those cases should be used against the industry, especially in terms of code and estimates (referencing your original statement). Such projects have a high chance to fail for both, timing and budget. One way to deal with it would be a "proof of concept project" prior to the main project. But I haven't seen many of those in the "real world"...
September 28, 2010 at 6:49 pm
Steve Jones - Editor (9/28/2010)
LutzM (9/28/2010)
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?I've had this happen before, and it still hasn't worked. Often it seems like you still have customers that don't really know what they want, or how things will change with a new system.
I've heard people talk about not having requirements, but it seems that in many domains, you don't really know what you want until you get something and can think about what to change.
When I've had the opportunity to really discuss the project with the customer and the end user, I've been able to work through what they really want. Usually it takes several iterations of discussion and design and going over the design and ramifications and suggestions of what might suit what they want better. It is my favorite way to approach a project and the only times when the project gets done on-time.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
September 28, 2010 at 8:36 pm
jcrawf02 (9/28/2010)
LutzM (9/28/2010)
Steve Jones - Editor (9/28/2010)
I am not sure I've had many projects at all in my lifetime that were on budget/on time unless they were trivial (< 1 week). It seems anything over that typically goes long.So does that mean we suck as an industry in
a) writing code
b) estimating
c) both
d) none of the above
I think the root cause is a lack of communication. Just think about it:
If you're a developer: How often did you have a chance to talk to the customer/client (= end user!!) directly in a meeting or workshop to verify what they were really looking for?
If you're a customer/client: How often did you have a chance to talk to the dev team directly to clarify your requirements (or what you think the requirements of the end users are)?
I've made the experience if you get the end users and the dev team together with a moderator (= translator for business requirements into software capabilities and vice versa = project manager?) at certain stages of a project it will be well worth the money. Even if it takes a day or two without coding for a few developer, it'll pay off.
Yes, I've done a few projects like that. All finished on time, within budget and with happy end users. And none of the projects ended with exactly what was specified at the beginning. Sometimes it was more, sometimes less but always something different.
That's called a Business Analyst. They work to get the job done right, PM works to get it done on time, leaves the rest of us just working. Beautiful thing when it works.
I would say that as a general rule, letting a "business analyst" anywhere near anything you seriosly want to happen is a big mistake. A person who can translate accurately between development speak and user speak is NOT called a business analyst - he or she is called a senior developer or a senior user! Business analysts exist solely to ensure that developers and users do not communicate.
In my experience, projects fail for one of five reasons, which in order of frequency are:
1) A programme champion (sometimes called a project manager) who understands neither the technology nor the business (nor how to use PERT or GANNT chart or anything else that MS project provides, but is going to use them anyway regardless of his incompetence to do so) is appointed with the power to change the requirements at will, change the manpower estimate at will, change the elapsed time estimate at will, cause the product to be released at any time regardless of the stage of development/qa, prevent product release even if qa is complete and there are no known issues, and ignore all input from anyone else.
2) A business analyst is put in to facilitate (management speak for "to prevent") communication between developers and users.
3) A product manager is put in to facilitate (management speak for "to prevent") communication between developers and marketeers.
4) The CEO believes the current bubble won't burst, so funding will happen regardless of progress.
5) What you are trying to work out how to do is so much further ahead of the state of the art that you can't do it within any reasonable distance of the allocated time.
Fortunately, I've mostly managed to be in environments where none of these things happen, in fact in environments where what Lutz describes happens instead. But I've seen all of them (mostly watching from the sidelines, luckily).
I'd recommend anyone who believes in "business analysts" or "product managers" or "programme champions" or any others of the modern batch of meaninglessly entitled obstacles to progress to read something like Francis Wheen's "How Mumbo Jumbo conquered the world" - although it doesn't talk at all about our business (computing, IT, databases, whatever) the lunacy that he points out is much the same lunacy as we have to cope with.
Tom
September 29, 2010 at 12:27 am
I got to "meet" the nicest person, today. I'm setting up to give a remote presentation and I got to work with Roy Ernest over the phone. Thanks for doing taking on the difficult part on all this, Roy.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2010 at 2:17 am
Tom.Thomson (9/28/2010)
...I would say that as a general rule, letting a "business analyst" anywhere near anything you seriosly want to happen is a big mistake. A person who can translate accurately between development speak and user speak is NOT called a business analyst - he or she is called a senior developer or a senior user! Business analysts exist solely to ensure that developers and users do not communicate...
Chinese whispers. User communicates requirements to BA who translates it into BA-speak (with an abundance of irritating jargon and made-up words) then passes it on to dev team to interpret. Most of the successful projects I've worked on have not involved a BA at all. By far the best have been migration or enhancement projects where the users have been instrumental in the redesign and welcome at developer Question Time.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
September 29, 2010 at 4:25 am
Jeff Moden (9/29/2010)
I got to "meet" the nicest person, today. I'm setting up to give a remote presentation and I got to work with Roy Ernest over the phone. Thanks for doing taking on the difficult part on all this, Roy.
Cool - I wish I had known. It might have been fun to listen in on you guys.
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
September 29, 2010 at 4:30 am
Tom.Thomson (9/28/2010)
Business analysts exist solely to ensure that developers and users do not communicate.2) A business analyst is put in to facilitate (management speak for "to prevent") communication between developers and users.
3) A product manager is put in to facilitate (management speak for "to prevent") communication between developers and marketeers.
Now that's a little unfair, Tom. I happen to know some seriously good BAs and PMs at my current workplace who are all about the communication and trying to understand everyone's needs. In fact, several of them are very good at facilitating projects.
That's not to say there are no bad ones. I've met plenty of bad ones. They don't usually last long at this place.
I agree with Steve's point that often the Business Unit (users) don't often know what they want until they're actually given it. I've been working a "brand new" project for a year now where we're all learning what the vendor software can do. As we discover more and more things about it, the BU changes their mind about how reports and final outputs should be configured. That's not the BAs / PMs fault. It's a learning experience for all of us.
Most projects I've worked on get scope changes due to one major issue. The IT department knows more about the business rules that the BU does. In the past, this has been a serious problem. Now that we have BAs and PMs who are paying attention to both sides, we're able to get requirements issues resolved in a timely manner and keep a majority of our deadlines.
Viewing 15 posts - 19,411 through 19,425 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply