The Optimists

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » The Optimists

60 posts, Page 1 of 6

1 2 3 4 5 »»»

The Optimists

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Monday, April 14, 2008 4:45 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:26 PM
Points: 31,425, Visits: 13,738

Comments posted to this topic are about the item The Optimists

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #484699

Jeff Moden

Posted Monday, April 14, 2008 8:41 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 2:32 PM
Points: 32,906, Visits: 26,792

Nicely said and nicely written, Steve... I'm not so generous in my thoughts about these kinds of Developers/DBAs (and I use the term loosly for folks with this type of problem). I've actually found that some people will take more time arguing about why something shouldn't be done rather than just doing it. Either that, or they're ignorant of what can actually be done because they haven't taken the time to do the research because of their attitude.

Heh... guess it's time to break these out... I wrote them several years ago (don't remember exactly when), borrowing heavily from Asimov...

Jeff Moden's Three Rules of DBA's.

1. A DBA may not injure data or performance of the data or, through inaction, allow data or performance of the data to come to harm.

2. A DBA must obey orders given to it by "Users", except where such orders would conflict with the First Law.

3. A DBA must protect "Users" existence as long as such protection does not conflict with the First or Second Law.

(Defininition of "Users" is anyone including but not limited to Developers, Designers, Data Modelers, Dev Managers, Project Managers, Customers, other DBA's, Ops personnel, one's immediate supervisor, or anyone else who, by command, code, design, setting, or device, may impart changes to the schema, the data, or the server).

--Jeff Moden

"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #484742

Andrew-566477

Posted Monday, April 14, 2008 11:21 PM

SSC Rookie

Group: General Forum Members
Last Login: Thursday, October 18, 2012 7:29 PM
Points: 47, Visits: 112

Great Editorial and a fantastic point.

I am a very hands on Systems Architect and I believe that in every single way it is the developers job to make the software do what the Business (the people who own the software) wants. And its the Businesses job to make the software do what the Users need. Often the Business and the developers are the same people, but regardless ... software is supposed to make lives easier, not more complicated.

Users should always feel there is somewhere they can go to detail difficulties with the software they use and ways to improve it, and be confident that the points raised will be addressed.

You used a saying that I have been using for a long time as well. When asked by a user if something is possible, I always respond with "Anything is possible, but how long do you have and how much money are you willing to spend".

Every developer should spend time sitting with users watching how the software is used. Those who dont will be amazed that the software is often used in ways never imagined.

Keep up the great work.

Andrew

Post #484761

Robert-378556

Posted Tuesday, April 15, 2008 3:19 AM

Ten Centuries

Group: General Forum Members
Last Login: 2 days ago @ 8:40 AM
Points: 1,078, Visits: 848

Good editorial. Jeff, well worded rules, they remind me of 3 rules of robotics. :)
Most of customer requests break the first rule. Then there are poorly thought requests that introduce a lot of side effect and the change over time, sometimes even to the opposite of original request.
So, if you reject requests as not doable, you're hurting your business. If you accept requests without brainstorming, you're hurting your and customer business.

Post #484832

Derek Dongray

Posted Tuesday, April 15, 2008 5:23 AM

Ten Centuries

Group: General Forum Members
Last Login: Monday, May 13, 2013 2:04 AM
Points: 1,342, Visits: 1,946

The usual problem is trying to follow part 1 of rule #2 (follow users' orders) while only bending rule #1 (i.e. a slight performance impact) when you'd really like to break rule #3 (i.e. kill the user who is making a request for a 'tiny change' which requires a major redesign of the database).

Actually, to be closer to the Laws of Robotics, rule #3 should be

3. A DBA must protect his own job as long as this does not conflict with rules #1 or #2.

Of course, we assume that the 'orders' only relate to things done to databases.

Derek

Post #484878

SuperDBA-207096

Posted Tuesday, April 15, 2008 5:39 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 02, 2013 12:15 PM
Points: 1,443, Visits: 711

Steve,
Well done!
Having worked as a developer, I've been on both sides of this.

While working at a bank, I was asked to do pretty much the same thing, fed the same lines almost verbatim.

Now, this was a web application, and there was a page counter which logged hits from each page to an SQL database. The enhancements they asked for required the creation of an additional 5 asp pages. The implementation was what they asked for; and it did exactly what they wanted.

I spent about 2 weeks creating the new features and guess what? They used 'em about 2-3 times a month, and it didn't justify the time spent on it.

On the other hand, there were some other features that did add alot of value, one 'bulk-change' utility I wrote saved the company countless man hours.

The point of this is - I think too much 'feature creation' without enough forethough can cause developers to get jaded or disheartened when they put alot of effort into something that doesn't get used.

Just my 02c...

Mark

Post #484890

Jeff Moden

Posted Tuesday, April 15, 2008 5:41 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 2:32 PM
Points: 32,906, Visits: 26,792

Heh... no, most people read the 3rd rule incorrectly. It should be more accurately but less politically correct as "The DBA must keep the User from hanging themself with poorly thought out plans and designs". :P

--Jeff Moden

Post #484892

a-241529

Posted Tuesday, April 15, 2008 6:22 AM

SSC Rookie

Group: General Forum Members
Last Login: Friday, August 03, 2012 8:15 PM
Points: 31, Visits: 85

One other problem with developers being unwilling to change their programs is because they write them in a way that is hard to change. They're afraid of breaking the program, because they didn't really understand the requirements when they wrote the application in the first place, so it barely works. About like a guy not wanting you to hang pictures on his plaster work, because he's afraid big chunks will fall out when you hammer it a bit.

John

Post #484926

chrisn-585491

Posted Tuesday, April 15, 2008 6:48 AM

SSC-Addicted

Group: General Forum Members
Last Login: Yesterday @ 7:32 AM
Points: 479, Visits: 1,263

I've seen both sides of the table. I've automated a reporting system that saved hundreds of man-hours and thousands of dollars. I've also had users send me spreadsheets of random, crappy, nasty, so-called data, documented by scans of sticky notes and want results instantly, just to find out later the project was a low priority. Crazy

Post #484954

thelabwiz

Posted Tuesday, April 15, 2008 6:54 AM

SSC Rookie

Group: General Forum Members
Last Login: Friday, October 22, 2010 10:22 AM
Points: 33, Visits: 41

Sometimes the best way give a user a new feature may be to think outside the (database) box.

Example: The manager of a group that had a service response time commitment (two business days) had been asking the database development group for a way to track the response time on each request for 2 years. The requests came in via an email form (which was automatically entered into the database) or by phone (manually entered into the database) for processing. The group that designed the database said that there was no way to provide a report of the normal business day (NBD) time each request required. When my manager became responsible for the system's maintenance, I got the "Get this guy off my back" assignment

Looking at the database structure showed that every step of the process was date/time stamped, so the total time for any request could be determined. I built a prototype Excel sheet that used VBA to extract the pertinent data and compute the NBD time. When the group's manager saw the unpolished prototype, his response was "I want that on my desk today." Although I added some functional enhancements later, the manager never asked that the (rather stark) user interface be improved. He was happy with the functionality; my boss was happy that the manager was happy; I was happy with the raise Wink

The only change to the database was a new user account with read (only) privileges to the needed data.

Post #484965

« Prev Topic | Next Topic »

60 posts, Page 1 of 6

1 2 3 4 5 »»»

Permissions