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


The Optimists


The Optimists

Author
Message
Bryant McClellan
Bryant McClellan
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1069 Visits: 542
I once had a manager who had pawned a system off on me, being unable to deal with the users, the system or its problems. Some time later I received some static form the same manager about the amount of time I spent on this system. My reply was to the effect that this was his idea, I took the load off him as he requested, and that he should have no further communications with me on the subject. Of course it was worded a little differently...

That system evolved from fixing problems to adding massive new functionality because the users perceived that I was willing to try something new. Not only did they get the features they wanted, the got levels of automation and independence from dual system entry.

But apparently I forgot part of those lessons. In a more recent meeting with a number of users and the CIO, I started to explain why it was not technically feasible to handle a certain request. I was very publicly chastised by the CIO, and for good reason, and told never to do this again. The issues were not technical but personal, as I realized later. The lesson was re-learned, from the opposite side and never forgotten.

Apparently the point here is that no matter how well-meaning we are as developers, there is no question that personal relationships also play a role. Those relationships an be repaired or destroyed on a single conversation, so be careful. The job you save may be your own.

FWIW, while the CIO has moved on, I have a great relationship with everyone else who was in that meeting, so I guess I DID learn something.

------------
Buy the ticket, take the ride. -- Hunter S. Thompson
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86530 Visits: 41098
thelabwiz (4/15/2008)
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.


I guess I don't understand that... sure, that's a decent solution... but why do you think that such a calculation is not possible in SQL Server? It's just data.

--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
John Kandrovy
John Kandrovy
SSC-Enthusiastic
SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)SSC-Enthusiastic (105 reputation)

Group: General Forum Members
Points: 105 Visits: 211
From the developer's perspective, if you are really trying to avoid scope creep then those moments of having a user pass on a request like that can be detrimental to getting the project done. Whenever we interact with our users we usually go with the party line response, "Email us with the request and we'll include it to our list of enhancements in later releases". It's really hard to say yes when you have to factor in the time and all the cause and effect.

In a recent episode, a user asked us to take something out of one of our reports... We did it and then 3 other departments started calling where did the column go?
Frank Buchan
Frank Buchan
SSC-Enthusiastic
SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)

Group: General Forum Members
Points: 127 Visits: 33
The "can do" attitude is fine (I have it, and always have), but we need to inject an additional dose of user-reality into analysis of from where the problem comes.

Part of the reason you get stonewalling has to do with failed requirements planning. Consider a developer who has spent months digging out requirements from a user group, done multiple run-ups of interfaces for them to test, and released a locked version of the business tool. A day later, one of the very same users begins making requests. Emotional human response to that aside, the suspicion is often that such a request means the requirements component was a farce on the user side. This is especially hard for a developer who puts great effort into doing things well and right, because it is a sign that the users did not deliver equal effort. The resistance in those cases isn't justified, but it does come from a real place: the concern the feature-add request is as ill-thought-out as the effort for requirements was. No one wants to do the same work multiple times just because the other side couldn't be bothered to communicate real needs. I'm not implying this is always the case, but it is an example of why the problem happens. Right now, I'm trying to rescue a project by a contractor who got trapped in this "new requirements" loop, and looking at their performance and documentation I can't fault them alone. A legitimate effort was stymied by the user view that an initial half-assed effort on their side could be offset by add-ons ad infinitum.

Another cause of the "technical barrier" attitude is often driven by the user-side (again, not really justified, only explained). That is where the user group consists of some users who have the power to make change-requests, and override others, but have no qualifications to do so. I recollect an awkward situation many years ago, when a time tracking application built by a company I consulted for was being driven change-to-change by the guy signing the cheques to pay for it. After a while, the only way to put the chap off changes was to start telling him they were technically dangerous, etc. The application in question worked to the relative satisfaction of all other users on the day of release, and some of the manager's changes were positive, but after a point they became vanity issues. (e.g., Lowly Fred asked for this and I'm tweaking it so it is my contribution.) In a circumstance like that, the developer has to make a difficult choice to protect core functionality or pursue the paying gig. As a businessperson, concern for the client's end-productivity should trump all.

A final explanation of the attitude problem comes from the all-too-common situation where the user requests are heavily weighted on superficialities. It seems these days, many of the projects I end up having to wrangle after the initial build, are completely stuck because somewhere along the way the colour of some screen element became of such concern no one was watching functionality. I recently was offered a save on a commercial website redesign that was eight months behind when the team working it was fired. I assessed it and ended up passing after two meetings, because I spent a total of eleven hours (paid, thankfully!) listening to the user group discuss irrelevancies. I tried to steer them with the fact they had a non-functional solution (core functionality was missing entirely), but they were so stuck on the colour scheme, placement of specific buttons, etc., it became obvious the bulk of the problem lay in that. I could see why the developers they fired were starting to use the "technical barrier" card with them. (Though I can also say the real issue was no management on the web development team's side.)

So, sometimes the attitude is coming from a real place, and the frustration that attends it is certainly easy to grasp.

At the end of it all, as well, we have a problem in the industry that exacerbates the issue: dependencies built on promises. How many times the last few years has an underlying technology actually been a barrier because it was late-delivered, had some show-stopping bug, etc. Developers are increasingly being handed more fragile tools by major providers, often too soon in the cycle and lacking stability, which makes delivering end-products tougher. It's not an excuse for the attitude, but it does seem to support the trend toward putting off the user requests as technically unsound -- because younger developers will do to their users exactly what the tool providers do to them. You need look no further than the fact MS still has no SP3 for SQL Server 2005. Granted, it's a slightly skewed example, but how can one explain the cumulative update stream but no SP, unless you invoke a phrase like, "technically, wrapping them in a SP...etc."

Anyhow, that's a slightly different perspecive from someone who is primarily a systems architect these days (whatever that means).
Bill Wehnert
Bill Wehnert
SSC-Enthusiastic
SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)SSC-Enthusiastic (197 reputation)

Group: General Forum Members
Points: 197 Visits: 67
I have always told any of my employers that "anything is possible, it just might not be probable". If a user told me that doing "x, y and z" would make their life easier, I would truly try to see how it could be done and what it would take time/effort to accomplish. Sometimes it just didn't make sense money wise (too much time to develop vs time saved), but I never wanted my first answer to be "no". Or a list of excuses as to why it couldn't be done.

I gave them the opportunity to describe their idea, flesh it out with them and offer suggestions and then took the time to see what it would take - putting the offer on the table for them to decide whether to go ahead or not.

I worked for CDW (Computer Discount Warehouse) years ago and the owner was big on certain slogans that were the companies mottos. My favorite was "Treat every customer like they are your only customer, because if you don't, they will be." I took that message to heart and have tried to follow that as closely as possible, whether the customer be internal or external.

Ad maiorem Dei gloriam
Old_D
Old_D
Valued Member
Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)

Group: General Forum Members
Points: 65 Visits: 86
Thanks Steve, Sometimes it seems like an us vs. them. Users seem to want more than what is possible. Developers act like the keepers of the data, and will only release dribs and drabs as we see fit. As a developer I have alway fought for the user, you know , a member of the team. Given enough time, developers should be able to produce a secure delivery of any data.
Miles Neale
Miles Neale
Hall of Fame
Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)

Group: General Forum Members
Points: 3042 Visits: 1694
Thank you for the wisdom in this. When we pass truths like this to the new and young we help them avoid the mistakes we ourselves have made.

Learning by experience takes a toll, learning from other's experience is healthier and allows us to get further sooner.

Appreciate your work!

Not all gray hairs are Dinosaurs!
a-241529
a-241529
SSC Rookie
SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)

Group: General Forum Members
Points: 37 Visits: 85
Hi Frank, just a note.

I always assume the end user has no clue what they really want, and I expect to have to redo work. I find often too many developers put too much effort into getting it "right" the first time and push the project way over budget. If developers took the mindset that the first version is to find out what the users really want, my guess is the projects would succeed more often overall, especially since the first version would at least have a chance to provide some value in the interim.

John
a-241529
a-241529
SSC Rookie
SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)

Group: General Forum Members
Points: 37 Visits: 85
Frank, by the way, I completely agree that major vendors need to spend more time streamlining their tools so they work bug free. It's hard to stay motivated on a project where you expended way too much effort tracking down a platform bug.

John
MIJ
MIJ
SSC-Enthusiastic
SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)SSC-Enthusiastic (155 reputation)

Group: General Forum Members
Points: 155 Visits: 497
I think everyone can agree that happy users are the goal (if you're a service provider, or a goal if you sell software), and that we sometimes need to remind ourselves of that. But it's usually a little more complicated than having a can-do attitude (although that's probably going to be a non-trivial part of any successful relationship). I liked Frank's analysis, particulary this bit:

Frank Buchan (4/15/2008)

A legitimate effort was stymied by the user view that an initial half-assed effort on their side could be offset by add-ons ad infinitum.


I've worked on that project as a developer, and it limped along for almost two years with three or four developers before finally being killed off. Not fun.

So my approach is more like this: Don't ask users what they want, figure out what they're trying to do and then tell them what they want. It's not as glib as it sounds, because if you really make an effort to learn their processes and make their goals your goals, it builds a level of trust that makes it a lot easier for you to make sound technical reccomendations and have them listened to. Of course that's hard, and it gets a lot harder if the customer is not sufficiently engaged in the project, but it ultimately takes two to Tango.
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