InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 25 May 2013 08:41:31 GMT20http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jeff Moden (1/28/2013)[/b][hr][quote][b]bryce.hill (1/25/2013)[/b][hr]It is painfull to make changes because you use SQL Server. It is a shite product that should never be used by a real company and not real companies use it. give up and embrace real technologies. Open source is the only true way. you are all wasting your time.[/quote]I'm curious. What do you use to manage multiple billions of "records" with? It's all open source, I assume, so you shouldn't mind sharing your methods.[/quote]Heh... yeah... I should have figured such a comment as nothing more than a drive by shooting. ;-)Sun, 03 Feb 2013 10:51:36 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]mhroche (2/3/2013)[/b][hr]While end users tell you all day what they want to be able to, do a system or tool cannot be successful without accomplishing whatever goal was set forth.Sometimes the challenge is deciphering what that goal is. #of users and groups and different business functions increase the complexity of that task drastically.To reiterate another poster's story about web solutions, in my experience Marketing teams are great stakeholders because of their creative ideas, but driving through the fun details like color, etc in early solution meetings can be challenging.Oh and the biggest gut shot is having something placed in 12-18 month backlog. With small data solutions my business clients have almost always proceeded to bootstrap an interim solution. Rock - hard place.[/quote]Indeed. Ask 10,000 people to describe in detail a "Perfect" anything (software application, healthcare plan, night out on the town, spouse ... anything), and you'll get 10,000 different answers. Any plan that involves a lot of people and includes the word "perfect" is doomed to failure. Always steer clear of that big rock.Sun, 03 Feb 2013 10:04:58 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxWhile end users tell you all day what they want to be able to, do a system or tool cannot be successful without accomplishing whatever goal was set forth.Sometimes the challenge is deciphering what that goal is. #of users and groups and different business functions increase the complexity of that task drastically.To reiterate another poster's story about web solutions, in my experience Marketing teams are great stakeholders because of their creative ideas, but driving through the fun details like color, etc in early solution meetings can be challenging.Oh and the biggest gut shot is having something placed in 12-18 month backlog. With small data solutions my business clients have almost always proceeded to bootstrap an interim solution. Rock - hard place.Sun, 03 Feb 2013 03:47:22 GMTnopeqwertyhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxNo doubt trolling for a 'laugh', but funnily enough I've designed & supported SQL systems that have processed ~$500M in transactions and that underpin global corporate processes.Likewise my company used to run SAP on SQL for America. Only strategic choices changed that as it was a perfectly fine platform.Tue, 29 Jan 2013 07:47:41 GMTjustinb486http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]bryce.hill (1/25/2013)[/b][hr]It is painfull to make changes because you use SQL Server. It is a shite product that should never be used by a real company and not real companies use it. give up and embrace real technologies. Open source is the only true way. you are all wasting your time.[/quote]Hey, kid: Get a job.Tue, 29 Jan 2013 07:18:53 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]bryce.hill (1/25/2013)[/b][hr]It is painfull to make changes because you use SQL Server. It is a shite product that should never be used by a real company and not real companies use it. give up and embrace real technologies. Open source is the only true way. you are all wasting your time.[/quote]I'm curious. What do you use to manage multiple billions of "records" with? It's all open source, I assume, so you shouldn't mind sharing your methods.Mon, 28 Jan 2013 16:39:08 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]bryce.hill (1/25/2013)[/b][hr]It is painfull to make changes because you use SQL Server. It is a shite product that should never be used by a real company and not real companies use it. give up and embrace real technologies. Open source is the only true way. you are all wasting your time.[/quote]Ha. I might say the same thing about some of the OSS products. OSS doesn't mean it's better or higher quality. It gives you more control and the chance to do be more flexible than you might with closed source, but it's not necessarily better.I've seen plenty of people think they're doing better with OSS and end up spending lots of money and time fixing crap that wasn't built right. I see plenty of security issues in both sets of software.SQL Server works well. Not perfect, but it's a solid product and it runs many, many solid sites for many real companies.Fri, 25 Jan 2013 10:47:50 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI actually enjoy learning a byzantine development system that with its own special ways of doing things. I am excited to be learning/using SQL Server. Who cares what the rest of the tech world is doing. I love SQL Server, IIS, MS Server, VB, it is a great ecosystem and if I learn it well I will be able to translate the skills into so many other environments.Fri, 25 Jan 2013 10:37:33 GMTludditehttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[code="plain"]You have a choice: Good Fast CheapPick any two.[/code]Not always agree with the trade off here.I've seen a few projects which are expensive because the specification was so bad or all encompassing that it dragged on for ages. All the extra time did was add cost with little extra quality. Nice tight guidelines and very focused knowledgable project manager and you can get good fast and cheap. These are the companies that generally lead the field. (not surprisingly)Tue, 22 Jan 2013 13:52:47 GMTDalkeithhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI don't have a problem with flexibility/changes per say. However, I do tend to have a problem with people/users who can't seem to make up their mind about what they want and are constantly changing their minds in mid-stream all the time. That is very frustrating, as well as it wastes alot of highly paid people's time and resources. Been there, done that. :-DTue, 22 Jan 2013 10:49:13 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jim P. (1/21/2013)[/b][hr]I've gotten in the habit with my manager of occasionally dropping this on her desk:[code="plain"]You have a choice: Good Fast CheapPick any two.[/code][/quote][code="plain"]You have a choice: Good Fast CheapPick at most two.[/code]Fixed it for you.As far as the original article, in some areas yes, you can work with the users to construct good alternatives. In some regulated fields, there are laws, regulatory requirements, directives, and the like which may sometimes directly conflict with what the user wants... and some, but not all, users just want what they want, and they want it now... There's not a lot of agreeing with them (without breaking the laws/regulations/directives/etc.) that can be done. The best I've found is "Please send me a written statement that you do want <law/regulation/directive> followed"... followed by putting your CV out on the street.Tue, 22 Jan 2013 10:28:07 GMTNadrekhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]dmbaker (1/21/2013)[/b][hr]I find it interesting that nobody has mentioned that building software, and modifying it, has an associated cost -- somebody has to pay for it.[/quote]"Pay" isn't always accurate. For internal software, with developers on salary, there is no "pay" that takes place which is explicit. Some other projects might get pushed back (or not). That makes it hard to develop payment. The level of payment also depends on whether or not a salaried developer must now work 50 hours instead of 40 or 45. In that case, the payment is very subtle.Tue, 22 Jan 2013 10:07:11 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxOne day an engineer set out to build a building. He asked the users, owner, and the city/county about the building. He filed the Environmental Impact Statement, all the permits, all the plans, and created all the blueprints needed. He did it all. Everyone was glad. Everyone was excited for the building would be all they wanted and it would do everything for them. The engineer worked with the builder and between them they built the building exactly as it was engineered. It was tall, it was warm, it was easy to get around, and it was what all the committees and authorities wanted. Everyone was happy. The building was exactly what was needed. All the systems and processes worked exactly as designed. It was perfect, One day a new manager was hired to work in the building. He looked around and saw all the building had to offer and then told the engineer "This building is good and for the most part it works for me. However, I could get some much more work done if the building would drive to my home and pick me up each morning at 7:15 so I could start work early and not worry about driving. Then what would really be ideal would be for it to take me home in the evening as well."The engineer said that it would be all but impossible this to happen. The building was not capable of moving, it could not drive at 65 on the freeway, and it could not get down the streets to the persons home. It was not made for that purpose. After the conversation both the engineer and the new manager believed they were right.M.Tue, 22 Jan 2013 09:55:22 GMTMiles Nealehttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Eric M Russell (1/21/2013)[/b][hr]The reality is that going directly to the DBA or developer may not be the best approach for an end user to propose some new application functionality, especially if it's done via an impromtu cubicle visit and the developer's mind is half occupied with troubleshooting some other issue. In a corporate setting, they should instead approach the business analyst or director, let them flesh out the requirement, and then they schedule a meeting with the developer to get input.[/quote]This is another "it depends"...Sometimes a quick chat with the developer will show either an easy way something can be done or the reasons it's hard. Going the analyst/director route may lead the feature bloat as the analyst/director adds a few other WIBNI's and presents the developer with something that would need a major rewrite to implement!Tue, 22 Jan 2013 08:12:40 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jim P. (1/21/2013)[/b][hr]I've gotten in the habit with my manager of occasionally dropping this on her desk:[code="plain"]You have a choice: Good Fast CheapPick any two.[/code]When she tries to up the workload.....[/quote]Thanks, that's a short and sweet way to put it.- webrunnerTue, 22 Jan 2013 07:49:26 GMTwebrunnerhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI've gotten in the habit with my manager of occasionally dropping this on her desk:[code="plain"]You have a choice: Good Fast CheapPick any two.[/code]When she tries to up the workload.I also pull that out when there is a "small" change or request on the table. They generally get the idea to re-evaluate and decide where to put it in the stack. I do my best to hear them out, and look at what they are requesting/suggesting and evaluate it on how hard it would really be to do.Mon, 21 Jan 2013 11:15:51 GMTJim P.http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxThe reality is that going directly to the DBA or developer may not be the best approach for an end user to propose some new application functionality, especially if it's done via an impromtu cubicle visit and the developer's mind is half occupied with troubleshooting some other issue. In a corporate setting, they should instead approach the business analyst or director, let them flesh out the requirement, and then they schedule a meeting with the developer to get input.Mon, 21 Jan 2013 10:32:41 GMTEric M Russellhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI find if you can spend a bit of time with your users you can sometimes spot things they are doing particularly awkwardly. It is sometimes possible to make suggested changes that you know you can make relatively easily but which save the user quite a bit of time. (being sneeky this can earn you loyalty points to offset against things that you think are unrealistic)Automating e-mail processes can be a real winner. I frequently see users printing off reports that they then scan and attach to e-mails. Spending half an hour to develop a function that will automate some of these very repetitive processes can be a real winner.I have been fortunate in being able to re-design a historical system primarily to get rid of technical debt. It made a massive difference although initially it looked like the same old system. (I was fortunate to be in an independent position that I was allowed to go ahead with that project because long term I could see that where we were heading we would need to re-design the structure to allow for easier adaption)There are managers out there that make critical policy alterations that are very difficult to incorporate into systems - that can be tricky.Mon, 21 Jan 2013 08:07:59 GMTDalkeithhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxIt is easy to lecture dBAs or developers for not being "customer-centric" or too pessimistic. Most people get into IT because they want to solve problems and create great solutions. Too often their innate drive for excellence is killed through the way IT work is managed. You mention workload, however, there are many other impediments to great customer support:- Lack of prioritization - Everything needs to be done ASAP, so people feel swamped- Lack of vision - What are the business objectives? How do we support those objectives? How should the system architecture be structured to support those objectives? What is the roadmap to get to that alignment?- The belief that all problems have a technical cause and/or a technical solution - In my experience, the tough problems are rooted in leadership and organizational problems. Creating solutions in a broken organizational/leadership environment just reinforces and speeds up the dysfunction.- Feature bloat - Poorly though out changes and additions can cause additional work with little additional business value.- Technical Debt - Things we know are broken or sub-optimal are never fixed in favor of new functionality- Lack of support - Training, tools, budget, people, etc.These are issues outside the control of the dBA. Today's emphasis on being positive has become a mantra that absolves management of their responsibility to create environments that allow employees to be successful. It is a "suck it up" attitude that eventually wears on employee morale to the point of disaffection. We need to stop worshiping at the altar of the "Hero Developer" and start engaging in systems thinking.Mon, 21 Jan 2013 07:54:09 GMTjazzbrazil2002http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI find it interesting that nobody has mentioned that building software, and modifying it, has an associated cost -- somebody has to pay for it.When users ask for modifications to systems we have to estimate the cost of the changes and discuss that with our users because they have to pay for the changes. Giving the users a sense of the cost of the modification helps them to better prioritize what they want. So, I never say "No, we can't do that." Rather, I say, I can do that, and here's how much it'll cost...do you still want to do it?"Of course, this depends heavily on us being able to provide accurate time and cost estimates, which is a whole other problem entirely.Mon, 21 Jan 2013 07:03:39 GMTdmbakerhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxThere was one key phrase in the request for the change that I would like to focus on: "small change." There are rarely any small changes. To evaluate the impact of the "small change" on the application is likely to be a major pain, let alone implement it.I was asked to add this one feature to an application I had just begun supporting. It was a "small change" because we were already doing something very similar. It had to be done in the next couple days. The code that did what was similar had been written by someone else for a very specific need, probably at 3:00 in the morning before it was needed (another "small change" that we need tomorrow). It had a ton of lines of code, tied specifically to the user interface. I had been told repeatedly never to change anything. I think that had they been open to a little longer time frame, I would have been less resistent. By the way, this company was especially didysfunctionalAs a developer, I don't think that the decision as to what should or should not be done is mine. My decision is how much more than a 40 hour week I am going to work. The business needs to decide what I should do in that time and more importantly what I am not going to do. Unless they want to add another resource, then they are going to have to specifically put other tasks on hold.Mon, 21 Jan 2013 06:13:14 GMTRussel Loskihttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxLike the other commenters, I've worked with developers who also liked to say no or go off the rails completely on a technology track which was not allowed or suitable.My favourite thing when dealing with numerous teams designing software, after going through their requirements, was to ask what their wishlist was, what would make their day and save lots of time & effort. This was usually met with surprise, because surely the amazing things they wanted couldn't be done. Very often, the wishlist either added minor modifications to the new feature designs or could actually be implemented pretty quickly & easily. This led to buy in from teams when I was working across multiple IT departments, so progressively made my job and access to secure data easier, as they saw the benefits that could be gained.Some people have an aptitude for extreme coding, reading & editing hex natively. Others can consult, design & develop well enough to have an impact. An important skill is spotting peoples skills and giving them the right jobs, so they're happy and productive and your customers are happy.Mon, 21 Jan 2013 03:22:44 GMTjustinb486http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxFrom what I've observed, there seems to be ever more red tape around what a developer is allowed to do. I used to be a developer and I got excited about the prospect of adding features. Over time it seems there are more and more constraints of risk and cost and developers end up having a negative view of every change as they're weary of coming up against glass half empty management decisions.I'm no longer a developer :-)Mon, 21 Jan 2013 03:04:18 GMTIsaac Murrayhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxWhat an interesting thread. I think there are some excellent insights in here.What I agree with most is that the effectiveness of the build and maintenance of systems is often a reflection of egos and attitudes, not of tools or processes.We can all do something about controlling our egos and recognising bad attitudes and habits.Another issue is 'Technical Debt'. This is a very handy term for something I have tried many times to explain to users: the more shortcuts you make now the more pain you will suffer in future.So I ask you all: Look up the term 'Technical Debt' and make sure your business users know what it is and know when it's happening!Mon, 21 Jan 2013 00:21:18 GMTnick.mcdermaidhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxDevelopers need to understand that the applications are not built for themselves and instead they are built for end users...keeping the end user happy should be the top most priority and should try to deliver whatever is requested for...at the same the developers need to use fair judgement to identify what can be built built on the system cos end users at times can be like this little kid in a candy store....:)Mon, 21 Apr 2008 15:00:46 GMTpseudoperhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Matt Miller (4/16/2008)[/b][hr]Quick ruling here - do middle managers who couldn't cut it as data trolls, and who now issue dictates as to how things should be implemented count as "users"? 'cause there are days when they stretch the limits of my self-control....:P:hehe:[/quote]Ummm... "s-e-l-f -c-o-n-t-r-o-l" ? Heh, when it comes to protecting the data, I have little. Fortunately, I have the backing of the higher levels of management... If I say "NO", it doesn't go. That includes a bunch of middle managers who think the only project in the world is theirs and don't understand why quality controls should be allowed to interfere with the crap code they want to put into the database just to say something is done...... and they're all getting used to pork chops. :PFri, 18 Apr 2008 17:05:34 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI am not a developer but have worked with several on projects. Some have the attitude that this is the way the program is designed and you should be able to use it this way. We purchased a third party application that has been full of bugs. For the past year we have met with the corporation's executives about the issues. The last meeting was with the Owner/CEO whose attitude was this is the way the program is designed and there's nothing better out there. Obviously, this person had a developer background and didn't care that everyone in our organization found the software difficult to use and full of bugs.Fri, 18 Apr 2008 11:52:29 GMTKbearhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxI usually would help the users to get what they wanted if their requests was reasonable and it would not take too long (less than 1 week). However the one who prevented me to do anything was usually my manager.To me, users knew the business and knew what they needed to do their job, not the project managers, not the business analysts and definitely not the IT manager.Thu, 17 Apr 2008 08:03:54 GMTLonerhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jeff Moden (4/16/2008)[/b]Heh... you saw the definition of "users" right after my 3 rules... developers ARE users and they can be the worst///[/quote]In some cases, devs are users, in that they use the databases (procs, etc.), but in this case, I'm specifically refering to the people who actually sit down in front of the final application to get their jobs done.In the case of some of these devs, they don't understand that my t-shirt ([url]http://www.thinkgeek.com/tshirts/itdepartment/595d/[/url]), does indeed count them amongst the users.Thu, 17 Apr 2008 07:18:39 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxNope... they would fall in the category of "abusers" or "Know-It-Alls"... heh... Know-It-Alls... funny how the abbreviation for that is "KIA"... :PWed, 16 Apr 2008 19:00:21 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jeff Moden (4/16/2008)[/b][hr]Heh... you saw the definition of "users" right after my 3 rules... developers ARE users and they can be the worst///[/quote]Quick ruling here - do middle managers who couldn't cut it as data trolls, and who now issue dictates as to how things should be implemented count as "users"? 'cause there are days when they stretch the limits of my self-control....:P:hehe:Wed, 16 Apr 2008 17:22:00 GMTMatt Miller (#4)http://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]GSquared (4/16/2008)[/b][hr][quote][b]Jeff Moden (4/16/2008)[/b][hr]Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... :D Of course, I never mind... it's all part of the 3 rules.[/quote]Working with people who know at least something about the internal workings is definitely nice, but does have it's ocassional problems.My current problem isn't users. Actually, in my short IT career, I've never had much of a problem with users. My current problem is with developers who know just enough SQL to amplify the damage they cause on a regular basis. I've told you a few of the horror stories (I still shudder when I think about the hierarchy that used nested cursors to call recursive UDFs, which used cursors). I have to admit, I haven't found a cure for that yet.On the sequence, yeah, I recognized the reason for it. It definitely works as-is. Printed it out and put it on the "wall" of my cubicle, next to some quotes from Phil Factor, a few comics cut from the local paper, a quote from the manual for a SCSI HDD (says, "1. Please to be inserting covers on pins.", as the instructions about using jumpers to set the SCSI ID), and a quote from a post on an SQL forum (might be this one), which says, "so I'm very confuse now Can anyone give me some clearly understanding on this". These things help me keep my perspective. :)[/quote]Heh... you saw the definition of "users" right after my 3 rules... developers ARE users and they can be the worst///Wed, 16 Apr 2008 13:21:59 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote][b]Jeff Moden (4/16/2008)[/b][hr]Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... :D Of course, I never mind... it's all part of the 3 rules.[/quote]Working with people who know at least something about the internal workings is definitely nice, but does have it's ocassional problems.My current problem isn't users. Actually, in my short IT career, I've never had much of a problem with users. My current problem is with developers who know just enough SQL to amplify the damage they cause on a regular basis. I've told you a few of the horror stories (I still shudder when I think about the hierarchy that used nested cursors to call recursive UDFs, which used cursors). I have to admit, I haven't found a cure for that yet.On the sequence, yeah, I recognized the reason for it. It definitely works as-is. Printed it out and put it on the "wall" of my cubicle, next to some quotes from Phil Factor, a few comics cut from the local paper, a quote from the manual for a SCSI HDD (says, "1. Please to be inserting covers on pins.", as the instructions about using jumpers to set the SCSI ID), and a quote from a post on an SQL forum (might be this one), which says, "so I'm very confuse now Can anyone give me some clearly understanding on this". These things help me keep my perspective. :)Wed, 16 Apr 2008 13:10:59 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxThanks for the replies and comments. There are some good ones in here and glad to see people are thinking a bit about this topic. Apologies for the delay in responding as I've been out of town and a little out of touch this week.I think most people get into this development to help people and take pride in what they've built, but users are hard on us, and I can see people getting cynical and tired of really trying hard to please those whimsical and often, unapprciative, end-users.I try not to do that here when you suggest things and think through if they make sense, why I should or might not decide to recommend changes (I can't make them), and if not, what good reason I have for not doing it. Please feel free to call me on that if I'm not being responsive.Wed, 16 Apr 2008 09:48:10 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxThanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... :D Of course, I never mind... it's all part of the 3 rules.Wed, 16 Apr 2008 09:34:15 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxgreat article, I can definately identify. I've found myself in several of these positions and I think my response often varies in proportion to the number of open initiatives, first hand knowledge of the system, scope of the request, and amount of support for said request.ie. If it's important enough to several users, but I do not have knowledge of the system, I will research it and estimate the net effect (time, cost, priority (provided I have time to do the research)), and then allow the user(s) or users group (If it affects other projects) to decide. Fortunately I have a users group that has some say over what gets done. But then again, if it affects bottom line or compliance directly, it almost certainly rises to the top.Wed, 16 Apr 2008 09:28:00 GMTEd Salvahttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxJeff, I love it! I'd reverse the 2nd and 3rd, but it's still quite good.On the article, I agree with the philosophy that the software exists only to serve the users, and it needs to be set up optimally to do so.One argument I've had with developers here is the old, "we can't please everyone" thing. Since they can't produce an interface that makes all the salespeople happy (for example), they produce one interface that doesn't really make anyone happy.My take on the thing is, take the top salesperson, and make an interface that perfectly suits his needs. His monthly sales volume is enough to pay the IT and IS salaries for a year, so a developer spending a few weeks/months making a perfect application for him would be good ROI. If it gets a 1% increase in his sales volume, and takes a month for one developer to accomplish, it will pay for itself in under a year (in terms of salary for the developer).Then, give all the salespeople a chance to play around with that interface. If simple customization can be accomplished on a per-user basis, do so. Otherwise, take the best salesperson who doesn't like that interface, and make something that works for him/her.By the time you have three significantly different interfaces, which make your top three salespeople extremely happy and help them produce, everyone else should be able to use one of those models, possibly with some help from dashboard type plug-ins that allow minor levels of user-by-user preferences.That way, the salespeople don't have to try to understand the system well enough to customize it to their own needs, you don't have to try to produce some sort of Frankenstein's monster of customizable interface with hundreds of plug-ins, and everyone should have something they can use to get good production.Doing it this way would take a few months of developer time per interface. It's not the most efficient use of developer time and would result in some duplicative work. But if it accomplishes as little as a 1% increase in sales efficiency, it more than pays for itself, and does so rapidly. (I can prove this number for this business. Other businesses may not have that same number.)Everyone nods their heads and goes, "oh, that makes sense", and then continues on with developing "one size fits none" software. It's very frustrating.Wed, 16 Apr 2008 09:17:16 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx[quote]Don't ask users what they want, figure out what they're trying to do and then tell them what they want.[/quote]I couldn't agree more. To quote (or paraphrase) Henry Ford: "If I had asked people what they wanted they would have told me to make a faster horse."I run into two main requirements challenges with users. The First is the user who tries to dictate design decisions. I would rather have a user say, "I need to be able to mark a record as obsolete." than say, "Put a checkbox in the database to mark a record as obsolete". Why? Because it might make more sense for that obsolescence to be tracked by date, or by who marked it, and that decision should be made collaboratively.The second is the user who doesn't know what is possible and therefore assumes that nothing can be improved. For example, I have a user who creates monthly reports by pulling data out of assorted databases and then dumping them into Excel and manipulating them into tables and graphs. Clearly, a lot of this process can be automated. But this user is certain that it can't be (and not just due to job security issues). I have just completed the first part of automating the reports and she is still certain that the rest of it can't be done.--JimFiveWed, 16 Apr 2008 08:58:16 GMTJames Goodwinhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspx:w00t: Well, unfortunately I felt like I was one of those people that do not want to help there users but that was until I read Jeff's 3 rules and I immediately felt better knowing that the times when users asked for something I said no because I knew for a fact that it would damage the data. Steve, I have done some introspection and yes, I found myself wanting and I pledge from now on I will do more to please my users and (as someone said) only after I have brainstormed the idea thoroughly. Thank you for your enlightening articles. You are like a preacher trying to keep his congregants on the right path.;)Wed, 16 Apr 2008 00:00:41 GMTManie Versterhttp://www.sqlservercentral.com/Forums/Topic484699-263-1.aspxThanks for the great editorial, Steve,Just for fun, I tried to figure out just how full the glass pictured in your editorial is.Given the shape of the glass, I used 3 imaginary nested cones pointing downward - just imagine the points of the cones all meeting a few inches below the bottom of the glass. It was a little hard to determine the top of the water line and the bottom (where the glass is thicker), but here is what I got:Volume of a cone = (1/3) * pi * r^2 * h radius r of top of glass (cone 1) 1.125 inchesheight h of cone 1 6.75 inchesvolume of cone 1 8.95 cubic inchesradius r of top of water (cone 2) 1.00 inchesheight h of cone 2 5.5 inchesvolume of cone 2 5.76 cubic inchesradius r of bottom of water (cone 3) 0.75 inchesheight h of cone 3 4.5 inchesvolume of cone 3 2.65 cubic inchesvolume of glass 6.30 cubic inches (volume of cone 1 minus volume of cone 3)volume of water 3.11 cubic inches (volume of cone 2 minus volume of cone 3) glass fullness 0.49 (volume of water divided by volume of glass)So the glass is indeed just about half full according to my calculations.The pessimists will say the glass is not half full, just 49% full. The optimists will round up to 50. :-)Cheers,webrunnerTue, 15 Apr 2008 10:45:24 GMTwebrunner