April 16, 2008 at 7:00 pm
Nope... they would fall in the category of "abusers" or "Know-It-Alls"... heh... Know-It-Alls... funny how the abbreviation for that is "KIA"... 😛
--Jeff Moden
April 17, 2008 at 7:18 am
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///
In some cases, devs are users, in that they use the databases (procs, etc.), but in this case, I'm specifically refering to the people who actually sit down in front of the final application to get their jobs done.
In the case of some of these devs, they don't understand that my t-shirt (http://www.thinkgeek.com/tshirts/itdepartment/595d/), does indeed count them amongst the users.
- 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 17, 2008 at 8:03 am
I usually would help the users to get what they wanted if their requests was reasonable and it would not take too long (less than 1 week). However the one who prevented me to do anything was usually my manager.
To me, users knew the business and knew what they needed to do their job, not the project managers, not the business analysts and definitely not the IT manager.
April 18, 2008 at 11:52 am
I am not a developer but have worked with several on projects. Some have the attitude that this is the way the program is designed and you should be able to use it this way. We purchased a third party application that has been full of bugs. For the past year we have met with the corporation's executives about the issues. The last meeting was with the Owner/CEO whose attitude was this is the way the program is designed and there's nothing better out there. Obviously, this person had a developer background and didn't care that everyone in our organization found the software difficult to use and full of bugs.
April 18, 2008 at 5:05 pm
Matt Miller (4/16/2008)
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:
Ummm... "s-e-l-f -c-o-n-t-r-o-l" ? Heh, when it comes to protecting the data, I have little. Fortunately, I have the backing of the higher levels of management... If I say "NO", it doesn't go. That includes a bunch of middle managers who think the only project in the world is theirs and don't understand why quality controls should be allowed to interfere with the crap code they want to put into the database just to say something is done...
... and they're all getting used to pork chops. 😛
--Jeff Moden
April 21, 2008 at 3:00 pm
Developers need to understand that the applications are not built for themselves and instead they are built for end users...keeping the end user happy should be the top most priority and should try to deliver whatever is requested for...at the same the developers need to use fair judgement to identify what can be built built on the system cos end users at times can be like this little kid in a candy store....:)
January 21, 2013 at 12:21 am
What an interesting thread. I think there are some excellent insights in here.
What I agree with most is that the effectiveness of the build and maintenance of systems is often a reflection of egos and attitudes, not of tools or processes.
We can all do something about controlling our egos and recognising bad attitudes and habits.
Another issue is 'Technical Debt'. This is a very handy term for something I have tried many times to explain to users: the more shortcuts you make now the more pain you will suffer in future.
So I ask you all: Look up the term 'Technical Debt' and make sure your business users know what it is and know when it's happening!
January 21, 2013 at 3:04 am
From what I've observed, there seems to be ever more red tape around what a developer is allowed to do. I used to be a developer and I got excited about the prospect of adding features. Over time it seems there are more and more constraints of risk and cost and developers end up having a negative view of every change as they're weary of coming up against glass half empty management decisions.
I'm no longer a developer 🙂
January 21, 2013 at 3:22 am
Like the other commenters, I've worked with developers who also liked to say no or go off the rails completely on a technology track which was not allowed or suitable.
My favourite thing when dealing with numerous teams designing software, after going through their requirements, was to ask what their wishlist was, what would make their day and save lots of time & effort. This was usually met with surprise, because surely the amazing things they wanted couldn't be done.
Very often, the wishlist either added minor modifications to the new feature designs or could actually be implemented pretty quickly & easily. This led to buy in from teams when I was working across multiple IT departments, so progressively made my job and access to secure data easier, as they saw the benefits that could be gained.
Some people have an aptitude for extreme coding, reading & editing hex natively. Others can consult, design & develop well enough to have an impact. An important skill is spotting peoples skills and giving them the right jobs, so they're happy and productive and your customers are happy.
January 21, 2013 at 6:13 am
There was one key phrase in the request for the change that I would like to focus on: "small change." There are rarely any small changes. To evaluate the impact of the "small change" on the application is likely to be a major pain, let alone implement it.
I was asked to add this one feature to an application I had just begun supporting. It was a "small change" because we were already doing something very similar. It had to be done in the next couple days. The code that did what was similar had been written by someone else for a very specific need, probably at 3:00 in the morning before it was needed (another "small change" that we need tomorrow). It had a ton of lines of code, tied specifically to the user interface. I had been told repeatedly never to change anything. I think that had they been open to a little longer time frame, I would have been less resistent. By the way, this company was especially didysfunctional
As a developer, I don't think that the decision as to what should or should not be done is mine. My decision is how much more than a 40 hour week I am going to work. The business needs to decide what I should do in that time and more importantly what I am not going to do. Unless they want to add another resource, then they are going to have to specifically put other tasks on hold.
Russel Loski, MCSE Business Intelligence, Data Platform
January 21, 2013 at 7:03 am
I find it interesting that nobody has mentioned that building software, and modifying it, has an associated cost -- somebody has to pay for it.
When users ask for modifications to systems we have to estimate the cost of the changes and discuss that with our users because they have to pay for the changes. Giving the users a sense of the cost of the modification helps them to better prioritize what they want. So, I never say "No, we can't do that." Rather, I say, I can do that, and here's how much it'll cost...do you still want to do it?"
Of course, this depends heavily on us being able to provide accurate time and cost estimates, which is a whole other problem entirely.
January 21, 2013 at 7:54 am
It is easy to lecture dBAs or developers for not being "customer-centric" or too pessimistic. Most people get into IT because they want to solve problems and create great solutions. Too often their innate drive for excellence is killed through the way IT work is managed. You mention workload, however, there are many other impediments to great customer support:
- Lack of prioritization - Everything needs to be done ASAP, so people feel swamped
- Lack of vision - What are the business objectives? How do we support those objectives? How should the system architecture be structured to support those objectives? What is the roadmap to get to that alignment?
- The belief that all problems have a technical cause and/or a technical solution - In my experience, the tough problems are rooted in leadership and organizational problems. Creating solutions in a broken organizational/leadership environment just reinforces and speeds up the dysfunction.
- Feature bloat - Poorly though out changes and additions can cause additional work with little additional business value.
- Technical Debt - Things we know are broken or sub-optimal are never fixed in favor of new functionality
- Lack of support - Training, tools, budget, people, etc.
These are issues outside the control of the dBA. Today's emphasis on being positive has become a mantra that absolves management of their responsibility to create environments that allow employees to be successful. It is a "suck it up" attitude that eventually wears on employee morale to the point of disaffection. We need to stop worshiping at the altar of the "Hero Developer" and start engaging in systems thinking.
January 21, 2013 at 8:07 am
I find if you can spend a bit of time with your users you can sometimes spot things they are doing particularly awkwardly. It is sometimes possible to make suggested changes that you know you can make relatively easily but which save the user quite a bit of time. (being sneeky this can earn you loyalty points to offset against things that you think are unrealistic)
Automating e-mail processes can be a real winner. I frequently see users printing off reports that they then scan and attach to e-mails. Spending half an hour to develop a function that will automate some of these very repetitive processes can be a real winner.
I have been fortunate in being able to re-design a historical system primarily to get rid of technical debt. It made a massive difference although initially it looked like the same old system. (I was fortunate to be in an independent position that I was allowed to go ahead with that project because long term I could see that where we were heading we would need to re-design the structure to allow for easier adaption)
There are managers out there that make critical policy alterations that are very difficult to incorporate into systems - that can be tricky.
January 21, 2013 at 10:32 am
The reality is that going directly to the DBA or developer may not be the best approach for an end user to propose some new application functionality, especially if it's done via an impromtu cubicle visit and the developer's mind is half occupied with troubleshooting some other issue. In a corporate setting, they should instead approach the business analyst or director, let them flesh out the requirement, and then they schedule a meeting with the developer to get input.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 21, 2013 at 11:15 am
I've gotten in the habit with my manager of occasionally dropping this on her desk:
You have a choice:
Good
Fast
Cheap
Pick any two.
When she tries to up the workload.
I also pull that out when there is a "small" change or request on the table. They generally get the idea to re-evaluate and decide where to put it in the stack. I do my best to hear them out, and look at what they are requesting/suggesting and evaluate it on how hard it would really be to do.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
Viewing 15 posts - 31 through 45 (of 59 total)
You must be logged in to reply to this topic. Login to reply