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 Tuesday, April 15, 2008 7:09 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 6:09 AM
Points: 846, Visits: 471
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
Post #484974
Posted Tuesday, April 15, 2008 7:09 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 7:48 PM
Points: 36,949, Visits: 31,455
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."

(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 #484976
Posted Tuesday, April 15, 2008 7:26 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, February 15, 2011 7:20 AM
Points: 89, 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?
Post #484995
Posted Tuesday, April 15, 2008 7:56 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, April 15, 2010 9:02 AM
Points: 85, 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).
Post #485036
Posted Tuesday, April 15, 2008 8:00 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, May 12, 2014 1:59 PM
Points: 155, Visits: 66
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
Post #485039
Posted Tuesday, April 15, 2008 8:13 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, November 26, 2010 7:48 AM
Points: 59, 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.
Post #485052
Posted Tuesday, April 15, 2008 9:21 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, August 7, 2014 3:34 PM
Points: 2,282, Visits: 1,341
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!
Post #485105
Posted Tuesday, April 15, 2008 9:22 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, August 3, 2012 8:15 PM
Points: 31, 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
Post #485108
Posted Tuesday, April 15, 2008 9:26 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, August 3, 2012 8:15 PM
Points: 31, 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
Post #485115
Posted Tuesday, April 15, 2008 9:47 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, August 13, 2014 11:01 AM
Points: 77, Visits: 441
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.
Post #485132
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse