SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Optimists


The Optimists

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)SSC Guru (142K reputation)

Group: Administrators
Points: 142964 Visits: 19424
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
My Blog: www.voiceofthedba.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)

Group: General Forum Members
Points: 209357 Visits: 41973
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Andrew-566477
Andrew-566477
Valued Member
Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)Valued Member (73 reputation)

Group: General Forum Members
Points: 73 Visits: 115
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
Robert-378556
Robert-378556
SSCrazy
SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)SSCrazy (2.3K reputation)

Group: General Forum Members
Points: 2330 Visits: 1010
Good editorial. Jeff, well worded rules, they remind me of 3 rules of robotics. Smile
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.
StarNamer
StarNamer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2736 Visits: 1992
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
SuperDBA-207096
SuperDBA-207096
SSCrazy
SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)SSCrazy (2.9K reputation)

Group: General Forum Members
Points: 2941 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
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)

Group: General Forum Members
Points: 209357 Visits: 41973
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". Tongue

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
a-241529
a-241529
Valued Member
Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)Valued Member (55 reputation)

Group: General Forum Members
Points: 55 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
chrisn-585491
chrisn-585491
Hall of Fame
Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)Hall of Fame (3.8K reputation)

Group: General Forum Members
Points: 3842 Visits: 2563
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
thelabwiz
thelabwiz
SSC Journeyman
SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)SSC Journeyman (83 reputation)

Group: General Forum Members
Points: 83 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 ;-)

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



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search