April 14, 2008 at 4:45 pm
Comments posted to this topic are about the item The Optimists
April 14, 2008 at 8:41 pm
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
Change is inevitable... Change for the better is not.
April 14, 2008 at 11:21 pm
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
April 15, 2008 at 3:19 am
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.
April 15, 2008 at 5:23 am
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
April 15, 2008 at 5:39 am
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
April 15, 2008 at 5:41 am
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". 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2008 at 6:22 am
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
April 15, 2008 at 6:48 am
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:
April 15, 2008 at 6:54 am
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.
April 15, 2008 at 7:09 am
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
April 15, 2008 at 7:09 am
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
Change is inevitable... Change for the better is not.
April 15, 2008 at 7:26 am
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?
April 15, 2008 at 7:56 am
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).
April 15, 2008 at 8:00 am
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
Viewing 15 posts - 1 through 15 (of 59 total)
You must be logged in to reply to this topic. Login to reply