April 15, 2008 at 8:13 am
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.
April 15, 2008 at 9:21 am
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!
April 15, 2008 at 9:22 am
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
April 15, 2008 at 9:26 am
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
April 15, 2008 at 9:47 am
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.
April 15, 2008 at 10:45 am
Thanks for the great editorial, Steve,
Just for fun, I tried to figure out just how full the glass pictured in your editorial is.
Given the shape of the glass, I used 3 imaginary nested cones pointing downward - just imagine the points of the cones all meeting a few inches below the bottom of the glass. It was a little hard to determine the top of the water line and the bottom (where the glass is thicker), but here is what I got:
Volume of a cone = (1/3) * pi * r^2 * h
radius r of top of glass (cone 1)1.125 inches
height h of cone 16.75 inches
volume of cone 18.95 cubic inches
radius r of top of water (cone 2)1.00 inches
height h of cone 25.5 inches
volume of cone 25.76 cubic inches
radius r of bottom of water (cone 3)0.75 inches
height h of cone 34.5 inches
volume of cone 32.65 cubic inches
volume of glass6.30 cubic inches (volume of cone 1 minus volume of cone 3)
volume of water3.11 cubic inches (volume of cone 2 minus volume of cone 3)
glass fullness0.49 (volume of water divided by volume of glass)
So the glass is indeed just about half full according to my calculations.
The pessimists will say the glass is not half full, just 49% full. The optimists will round up to 50. 🙂
Cheers,
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
April 16, 2008 at 12:00 am
:w00t: Well, unfortunately I felt like I was one of those people that do not want to help there users but that was until I read Jeff's 3 rules and I immediately felt better knowing that the times when users asked for something I said no because I knew for a fact that it would damage the data. Steve, I have done some introspection and yes, I found myself wanting and I pledge from now on I will do more to please my users and (as someone said) only after I have brainstormed the idea thoroughly. Thank you for your enlightening articles. You are like a preacher trying to keep his congregants on the right path.;)
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
April 16, 2008 at 8:58 am
Don't ask users what they want, figure out what they're trying to do and then tell them what they want.
I couldn't agree more. To quote (or paraphrase) Henry Ford: "If I had asked people what they wanted they would have told me to make a faster horse."
I run into two main requirements challenges with users.
The First is the user who tries to dictate design decisions. I would rather have a user say, "I need to be able to mark a record as obsolete." than say, "Put a checkbox in the database to mark a record as obsolete". Why? Because it might make more sense for that obsolescence to be tracked by date, or by who marked it, and that decision should be made collaboratively.
The second is the user who doesn't know what is possible and therefore assumes that nothing can be improved. For example, I have a user who creates monthly reports by pulling data out of assorted databases and then dumping them into Excel and manipulating them into tables and graphs. Clearly, a lot of this process can be automated. But this user is certain that it can't be (and not just due to job security issues). I have just completed the first part of automating the reports and she is still certain that the rest of it can't be done.
--
JimFive
April 16, 2008 at 9:17 am
Jeff, I love it! I'd reverse the 2nd and 3rd, but it's still quite good.
On the article, I agree with the philosophy that the software exists only to serve the users, and it needs to be set up optimally to do so.
One argument I've had with developers here is the old, "we can't please everyone" thing. Since they can't produce an interface that makes all the salespeople happy (for example), they produce one interface that doesn't really make anyone happy.
My take on the thing is, take the top salesperson, and make an interface that perfectly suits his needs. His monthly sales volume is enough to pay the IT and IS salaries for a year, so a developer spending a few weeks/months making a perfect application for him would be good ROI. If it gets a 1% increase in his sales volume, and takes a month for one developer to accomplish, it will pay for itself in under a year (in terms of salary for the developer).
Then, give all the salespeople a chance to play around with that interface. If simple customization can be accomplished on a per-user basis, do so. Otherwise, take the best salesperson who doesn't like that interface, and make something that works for him/her.
By the time you have three significantly different interfaces, which make your top three salespeople extremely happy and help them produce, everyone else should be able to use one of those models, possibly with some help from dashboard type plug-ins that allow minor levels of user-by-user preferences.
That way, the salespeople don't have to try to understand the system well enough to customize it to their own needs, you don't have to try to produce some sort of Frankenstein's monster of customizable interface with hundreds of plug-ins, and everyone should have something they can use to get good production.
Doing it this way would take a few months of developer time per interface. It's not the most efficient use of developer time and would result in some duplicative work. But if it accomplishes as little as a 1% increase in sales efficiency, it more than pays for itself, and does so rapidly. (I can prove this number for this business. Other businesses may not have that same number.)
Everyone nods their heads and goes, "oh, that makes sense", and then continues on with developing "one size fits none" software. It's very frustrating.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 16, 2008 at 9:28 am
great article, I can definately identify.
I've found myself in several of these positions and I think my response often varies in proportion to the number of open initiatives, first hand knowledge of the system, scope of the request, and amount of support for said request.
ie. If it's important enough to several users, but I do not have knowledge of the system, I will research it and estimate the net effect (time, cost, priority (provided I have time to do the research)), and then allow the user(s) or users group (If it affects other projects) to decide.
Fortunately I have a users group that has some say over what gets done.
But then again, if it affects bottom line or compliance directly, it almost certainly rises to the top.
-- Optimist with experience and still learning
April 16, 2008 at 9:34 am
Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.
My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... 😀 Of course, I never mind... it's all part of the 3 rules.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 9:48 am
Thanks for the replies and comments. There are some good ones in here and glad to see people are thinking a bit about this topic. Apologies for the delay in responding as I've been out of town and a little out of touch this week.
I think most people get into this development to help people and take pride in what they've built, but users are hard on us, and I can see people getting cynical and tired of really trying hard to please those whimsical and often, unapprciative, end-users.
I try not to do that here when you suggest things and think through if they make sense, why I should or might not decide to recommend changes (I can't make them), and if not, what good reason I have for not doing it. Please feel free to call me on that if I'm not being responsive.
April 16, 2008 at 1:11 pm
Jeff Moden (4/16/2008)
Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... 😀 Of course, I never mind... it's all part of the 3 rules.
Working with people who know at least something about the internal workings is definitely nice, but does have it's ocassional problems.
My current problem isn't users. Actually, in my short IT career, I've never had much of a problem with users. My current problem is with developers who know just enough SQL to amplify the damage they cause on a regular basis. I've told you a few of the horror stories (I still shudder when I think about the hierarchy that used nested cursors to call recursive UDFs, which used cursors). I have to admit, I haven't found a cure for that yet.
On the sequence, yeah, I recognized the reason for it. It definitely works as-is. Printed it out and put it on the "wall" of my cubicle, next to some quotes from Phil Factor, a few comics cut from the local paper, a quote from the manual for a SCSI HDD (says, "1. Please to be inserting covers on pins.", as the instructions about using jumpers to set the SCSI ID), and a quote from a post on an SQL forum (might be this one), which says, "so I'm very confuse now Can anyone give me some clearly understanding on this". These things help me keep my perspective. 🙂
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 16, 2008 at 1:21 pm
GSquared (4/16/2008)
Jeff Moden (4/16/2008)
Thanks, Gus... the order was to preserve Asimov's original order and because they can be broken down more simply as "Protect the data, protect the project, protect the user" and in that order.My biggest problem is that I have a bunch of users (Business Analysts, Systems Analysts, and "end users) that were programmers in a previous life. In most cases, it helps a lot... in many cases, they think they're smarter than the resident data-troll and I frequently have to prove to them, with code examples, why I told them the method they want either won't work or how it will hurt performance or how it has the potential for damaging the data. It's almost like a real life forum in many cases... 😀 Of course, I never mind... it's all part of the 3 rules.
Working with people who know at least something about the internal workings is definitely nice, but does have it's ocassional problems.
My current problem isn't users. Actually, in my short IT career, I've never had much of a problem with users. My current problem is with developers who know just enough SQL to amplify the damage they cause on a regular basis. I've told you a few of the horror stories (I still shudder when I think about the hierarchy that used nested cursors to call recursive UDFs, which used cursors). I have to admit, I haven't found a cure for that yet.
On the sequence, yeah, I recognized the reason for it. It definitely works as-is. Printed it out and put it on the "wall" of my cubicle, next to some quotes from Phil Factor, a few comics cut from the local paper, a quote from the manual for a SCSI HDD (says, "1. Please to be inserting covers on pins.", as the instructions about using jumpers to set the SCSI ID), and a quote from a post on an SQL forum (might be this one), which says, "so I'm very confuse now Can anyone give me some clearly understanding on this". These things help me keep my perspective. 🙂
Heh... you saw the definition of "users" right after my 3 rules... developers ARE users and they can be the worst///
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2008 at 5:22 pm
Jeff Moden (4/16/2008)
Heh... you saw the definition of "users" right after my 3 rules... developers ARE users and they can be the worst///
Quick ruling here - do middle managers who couldn't cut it as data trolls, and who now issue dictates as to how things should be implemented count as "users"? 'cause there are days when they stretch the limits of my self-control....:P:hehe:
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 15 posts - 16 through 30 (of 59 total)
You must be logged in to reply to this topic. Login to reply