Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

The Optimists Expand / Collapse
Author
Message
Posted Monday, April 14, 2008 4:45 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 4:29 PM
Points: 32,819, Visits: 14,965
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
Posted Monday, April 14, 2008 8:41 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 9:45 PM
Points: 36,013, Visits: 30,300
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."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #484742
Posted Monday, April 14, 2008 11:21 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC 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
Posted Tuesday, April 15, 2008 3:19 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, October 21, 2013 12:21 PM
Points: 1,149, Visits: 871
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
Posted Tuesday, April 15, 2008 5:23 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, February 18, 2014 7:14 AM
Points: 1,344, Visits: 1,983
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
Posted Tuesday, April 15, 2008 5:39 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP 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
Posted Tuesday, April 15, 2008 5:41 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 9:45 PM
Points: 36,013, Visits: 30,300
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
"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."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #484892
Posted Tuesday, April 15, 2008 6:22 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC 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
Posted Tuesday, April 15, 2008 6:48 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, April 04, 2014 8:42 AM
Points: 598, Visits: 1,504
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.
Post #484954
Posted Tuesday, April 15, 2008 6:54 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC 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

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 »

Add to briefcase 12345»»»

Permissions Expand / Collapse