Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Enterprise development: Its ok to say No!

by demerphq (Chancellor)
on Dec 16, 2003 at 11:55 UTC ( #315028=perlmeditation: print w/ replies, xml ) Need Help??

I've noticed in my time developing for a large enterprise that there are three broad categories of developer. (Of course there are more, but for the sake of this discussion I believe this distinction is sufficient.) They are:

The profi programmer
This type of programmer is usually (but by no means always) a permanent employee. They usually work in a dedicated development group, and tend to take a long view of situations. The code they write tends to be, by necessity, written to handle the bigger picture, such as long term maintenance, portability, extensibility.
The happy customer programmer
Often, but not always, this type of programmer is a contractor. Their primary focus is to keep the customer happy. This means they tend to avoid any form of confrontation with the business contacts they work with. They usually work with contract renewal or immediate customer gratification as their primary objective. (Note that gratification is not the same as satisfaction. Gratification is an ego thing, satisfaction is a results thing. They are often orthogonal.)
The JGID programmer (Just Get It Done)
This type of programmer takes the shortest path to a working solution. Meeting customer requirements is important, but if corners need to be shaved to get the project working quickly then to hell with the spec. This type of programmer usually has no long term vision at all and simply does their best to get a particular problem off their table as quickly as possible, no matter how stupid the project is.

I bring this up because I have observed a pattern related to these three personalities. Its common I find to have people from the business approach a developer and say something like "can you do X, Y, and Z using P, over T without using U?".

The JGID, tends to evaluate the situation quickly, and then say yes or no based on their tools and skills. If they say yes then they implement quickly, with minimal questions, and with minimal thought about how their work fits into their companies bigger IT/IS framework. If as they go they discover the specs are insufficient they tend to quickly get frustrated, and will drop the project at the first opportunity, or simply make quick decisions on their own, and hand over a partial solution to the customer with a comment like "should have given me better specs, you get what you ask for."

The happy customer programmer tends to simply say yes. They don't mind going back and forth to business to refine, redo, and re implement things. As long as the customer is smiling every time they walk away what they have actually produced is irrelevant. And if it takes an inordinate amount of time, well that's just fine, as I said usually they are contractors and are thus quite happy to waste time.

The profi tends to look at such a scenario and say: "No I cannot do this. First off what you have there is a solution. I don't implement solutions. I solve problems. Come back to me and tell me what you want done, and I'll put together some proposals for you, but I certainly wont do what you've just asked until you tell me a lot more about the real problem at hand." They are worried much more about the overall framework more than any individual project. They know that simply deploying a crappy solution, no matter how happy this will make some particular business person, is not the prime objective. If this solution ends up wasting hours or weeks of valuable time and resources then they don't do it.

Now personally at various times I've been all of the above and worked with all of the above. But I've come to the conclusion that its only the profi that I want to be and work with. The other types are long term a waste of time.

As an enterprise programmer you don't work for a individual. You work for the company. And if saying no to some (possible self important) businessman is long term in the companies benefit then you should say so. Saying No to the business is fine if you can justify it. Saying yes to business and then wasting your time and their money does no-one any good.

So for those in the position to do so (I acknowledge that many contractors aren't in this position), when in your judgement you think something is a bad idea Just Say NO. The business almost never can do anything against you if you do so. It will be their job to justify why you should have said yes. And frankly they probably wont even bother. IMO most likely you and everyone else will be better off. Also, once in a while you'll find that business person comes back with a good description of the underlying problem and lets you propose some solutions that are viable. Often they are quite surprised to discover that Y and Z are already done, there is no reason to either use P or not use U and T has nothing to do the problem anyway. Even better, when this happens the customer usually sings your praises loud and far. (Which is always nice :-)

I look forward to having this meditation ripped to shreds by the many more experienced monks than I. But for now, the most important lesson I've learned that im trying to pass on here is that saying no isn't a bad thing at all.

This also has some overlap in the monastery. Questions here are often along the line of "how do I implement solution X", instead of "how do I solve problem Y". Its the latter ones that I tend to answer. The former ones (unless interesting on their own) are usually ignored.

PS: "profi" means professional. (Possibly with subtle overtones of "permie" as well) Which is not to imply that contractors and the JGID aren't professional, its just that the term that has been associated in my mind with this type of programmer.


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi


Comment on Enterprise development: Its ok to say No!
Download Code
Re: Enterprise development: Its ok to say No!
by kodo (Hermit) on Dec 16, 2003 at 12:25 UTC
    It's the same for me, I always ask what the problem is because usually the way our managers want to have something solved is by far not the perfect way.
    All they usually come up with is "some way" they know because they've heard about it or seen something about it sometime ago while having no clue if it's still a good way to solve the problem nowadays. Or they just don't know the alternatives...
    If I would just have to implement other people's solutions I would have quit my job already a long time ago, because it would just bore me to death.

    But sometimes it also happens that they just want solution X to be implemented if it's a good idea or not. Managers sometimes just are like that, they get something in their brain and won't agree to that it's a bad idea whatever arguments you come up with. A good example here is "java/J2EE" which is IMO often used for things it shouldn't be. I really hate that but you finally just have to accept it sometimes I guess...

    I really love it to say "see that's why I said we should use Y for that and not X!" once a project is finished and people start to realise that the result is a piece of crap....

      But sometimes it also happens that they just want solution X to be implemented

      My response is usually that they should state in writing that they understand my objections and that they intend to override them anyway. Only with this in hand do I travel down the "you must" road. That way when it all goes tits up the evidence of the responsible party is in hand. The funny thing that i've found however is that managers dont like to do this for some reason and end up backing off. Its amazing to see the bravado vanish when you say "Fine. give it to me in writing and no problem." I suppose the thought that you might be right and they might be wrong is too much for them. But off course if you take this approach, make sure you are in fact right. :-)


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        I also did that in the past but never got back that requested writing ;)
        But really depends on who is giving you the job it's sometimes better (for me) to just agree after some discussion you know...
Re: Enterprise development: Its ok to say No!
by DrHyde (Prior) on Dec 16, 2003 at 12:40 UTC
    But I've come to the conclusion that its only the profi that I want to be and work with

    I want to be and work with people who are a mixture of all three of your types.

    As a professional I like to think of what I do as engineering as opposed to a craft or a pure art - and yes, just like with the engineer who designs and builds railways, maintainability, extensibility and scalability are important.

    However, I need to keep the customer (internal or external) happy because that keeps my boss happy and that keeps me in well-paid employment. Confrontation and criticism are just fine, provided that they are reasoned and polite. As an example, I've just today done a code freeze on one of my projects so it can have a few weeks of testing before the inevitable bug-fixing, and then deployment. If I hadn't said "no" to some of the features that were requested, I'd still have another few months of development to go. By saying "no" a few times I could give the customers 90% of what they wanted in a third of the time it would have taken to give them everything. I designed the system so that I can add their extra whizzy features later, although I'll bet a small sum that they find out that they don't really need them. And throughout development, I've kept the customers informed of progress. That's gratification.

    But there are also times when I just need to get something - anything - done. A few months ago, two of the people in my group were spending an age doing repetitive data entry when their expensive time was better spent doing other stuff. So I automated it for them, after perhaps fifteen minutes of discussion. The requirement was simple, and I implemented it in maybe another fifteen minutes. Then I tested it on some sample data, it appeared to work, so we deployed it. And it has continued to work for some months now, freeing up a lot of time and making the group more productive. When I did the quick and dirty hack, I made it perfectly clear that what I was doing was ugly and unmaintainable, and that if the requirements changed it would have to be treated as a whole new project and properly specced out and planned that time. Everyone's happy with that.

    So keeping the customer happy is fine provided it is a result of good work and good communication rather than kowtowing. JGID is fine, provided you are prepared to also say "no", draw a line in the sand and say "ugly hacks go this far and no further".

Re: Enterprise development: Its ok to say No!
by crouchingpenguin (Priest) on Dec 16, 2003 at 13:11 UTC

    I think what you are describing fundamentally breaks down to different levels of skill sets and experience.

    Your JGID programmer is usually the greener programmer (notice I didn't say younger) who wants to jump into the project to get his/her hands dirty and gain experience. This isn't a bad characteristic, it just needs to be carefully watched and cultivated. Sometimes this type of programmer is extremely handy with finishing details or peripheral components that need to be completed quickly. With a little guidance from those with more experience and skill (journeymen and craftsmen), this person will eventually start seeing the larger picture.

    Your "happy customer programmer" to me reminds me of myself not long ago. I was all about delivering solutions that could later be built on top of. I don't think this type of programmer is lacking due to this drive. In fact, if you look at the building blocks of a lot of frameworks, you will see their origins in this type of development. Of course, they always tend to need heavy refactoring due to some of the broad design oversights. But that is where the "profi" programmer comes in.

    Your "profi" programmer is definitely the master of the guild. He is most likely heading the team, overseeing the design and delegation of the project's subsystems. I don't think your definition covers all aspects of what I would consider to be this type of person. Some can easily interface with management types and further the development teams needs. Some simply butt heads with anyone outside their group or control. This broad range is always due to the experience given to them as they moved up the chain from apprenticeship to master craftsman. It is also this person who has the most influence on the greener programmers beneath him/her.

    Every team is different, just as every person is. It is handy to be able to quickly identify a situation or team so that you can normalize yourself quickly. But I think you lose a lot if you try to be too rigid in your definitions. Believe me, even your "profi" master craftsmen benefits from those greener apprentice programmers. How many times have you gained from simply explaining to someone how to get something done, while also at the same time imparted your wisdom on the why's and how's? Or how about that fresh perspective from a new pair of eyes?

    I guess my point is, give everyone a fair chance to contribute. You will be surpised when you learn things from those less experienced than you.


    cp
    ----
    "Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic."
Re: Enterprise development: Its ok to say No!
by Abigail-II (Bishop) on Dec 16, 2003 at 13:17 UTC
    But I've come to the conclusion that its only the profi that I want to be and work with.

    That's a short sighted view, and isn't acceptable in the long run. Topping the 'profi programmer' is the programmer who can shape shift from one class of programmer to another, and knows when to be what kind of programmer.

    Anecdote: I work for a company that has written software since the early 70's (I've coworkers that have been with the company or its predecessor for 30 years). I work in a department that is actively maintaining software that was written in the 70's (lots of FORTRAN and Pascal code) - part of the software is an OS that was initially written in PDP assembler, was later emulated on top of VMS, SCO, and is now running on top of Linux and Windows; where it runs as a secondary OS. We know all about portability, extensibility and maintainability.

    We recently had a problem. As part of the nightly back procedure, the secondary OS calls a Linux program. This program does some mounting and umounting of disks hanging off fibre-channel devices and then queries /proc to get an impression of what disk are available. Due to a bug in the fibre channel driver, once in a blue moon, this generates a kernel oops, causing the kernel to kill the program, which in turn causes the secondary OS to dump and restart itself. For a particular customer, this was reason to not take a new release into production.

    There were several ways of approaching this problem. The 'profi' programmer approach would be to dive into the driver sources try to find the problem, and fix the driver. The problem is, you can't estimate how long it's going to take, as it requires to become familiar with the driver. The 'happy customer' programmer approach is to write a wrapper around the program that causes the kernel oops, which just restarts the original program if causes an oops.

    In the end, we did both. I wrote a shell script wrapper, and we send that to the customer the next day. Customer happy. Later, we ripped a newer version of the driver out of a newer kernel and implanted it in the kernel we're working with, and luckely that fixed the problem.

    What I am trying to say is that the bigger picture is important. Maintainability, portability, extensibility, it's all important. But in the end, what's really important is (happy) customers. If your customers aren't happy - they leave. If they leave, your product can be fantastic, you won't survive. A good programmer balances the customers wishes and the development group wishes into an ideal blend.

    Abigail

      I see that as not so much of a 'shape shift' as 'knowing when a quick hack is the acceptable short term solution'. It's like saying, "this will keep you up and running for the immediate future, BUT it is not a proper solution"

      It's more like the profti is a superset of the qualities other types rather than a different species all together...

      The true headaches begin when the PHBs on a project try to coerece a Profti into a HCP because their ideas are poor and s/he isn't 'yes man'ing enough. /me winks at jeffa

      /\/\averick
      OmG! They killed tilly! You *bleep*!!

Re: Enterprise development: Its ok to say No!
by TVSET (Chaplain) on Dec 16, 2003 at 13:17 UTC
    But for now, the most important lesson I've learned that im trying to pass on here is that saying no isn't a bad thing at all.

    OTOH, some of us are so good at saying "No" that it becomes difficult to say "Yes" once in a while. :)

    PS: Nice meditation. ++

Re: Enterprise development: Its ok to say No!
by dragonchild (Archbishop) on Dec 16, 2003 at 16:56 UTC
    Saying "No" ... You should never say "No". Remember - you're are, first and foremost, as a human being in some organization, a salesperson. It doesn't matter what position you do or what skills you have. It doesn't matter because you are attempting to sell your ideas / experience / qualifications / whatever to someone else.

    If you ask an experienced salesperson, you'll learn that one should always emphasize the positive and de-emphasize the negative.

    Don't say "No, you stupid ass!". Say "Hmmm ... could you explain a little more what you're trying to do?"

    Don't say "No, you bumbling fool!". Say "Let me study the problem and I'll get back to you tomorrow."

    In short, coddle the stupid bumbling fool/ass, make them happy, and now you've got a friend for later usage.

    P.S. - Do you ever want to know whether the accountant is using method A or method B? You have to train your customers to think the same about you. And, do you think of an accountant as an engineer or a craftsman?

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      "No" is a perfectly legitimate response to any question as long as it is followed up by the reason why. An experienced salesman will always try and understand the needs of the customer and work with them to provide useful information. A salesman who adopts this approach is likely to initiate a long term relationship which leads to repeat sales.

      The ability to say "No" is vital for survival. How many children would be around today if their parents had said "Jonny, I think that you had better consider the effect that putting your finger in the electrical socket will have on your future" rather than "No! Don't do that!!".

      Adults are like children but with less honesty. We spend all our time trying to please others even if this means hiding the truth and distorting the facts. Taken to extremes, this is called politics - we all trust politicians, don't we?

      Technology projects of any kind can succeed or fail for numerous reasons. Lack of trust and poor communication between implementors and decision makers plays an important part in how a small mistake can become a catastrophe. The ability to say "No" is a vital first step to truth and openness.

Re: Enterprise development: Its ok to say No!
by revdiablo (Prior) on Dec 16, 2003 at 18:11 UTC

    I don't have much in the way of real insight on the matter (frankly, Abigail's response said everything I might say, and much better than I would say it), but I thought it interesting that several people have responded along the lines of an Engineer vs Craftsman analogy. I'd like to think they're in this frame of mind because of my very recent Meditation on the subject ((OT) Programming as a craft), but maybe I'm just being presumptuous. In any case, nice Meditation.

Re: Enterprise development: Its ok to say No!
by jZed (Prior) on Dec 16, 2003 at 19:05 UTC
    First, I agree entirely, "Just say NO" when a spec is doomed to failure, or is against your principles, or is just plain a bad thing (tm). I've worked mostly as a contractor and I have lost one or two bids by saying NO, but the bids that I got even when I did say NO were the best gigs I had - an employer who says "hmm, this guy has the guts to say NO, maybe he knows something I don't" is a good employer.

    From the contractor's perspective, I've most often seen this combo - 1) the MIS department which takes the big picture only in so far as the entire goal is stability, lack of change, and lack of users bugging them 2) various web weenies who like making cool effects but have no concept of how what they do fits into any larger picture 3) the brilliant, innovative and humble contractor :-).

Re: Enterprise development: Its ok to say No!
by Anonymous Monk on Dec 16, 2003 at 21:02 UTC

    You forgot the stereotype-everything-and-post-it-on-perlmonks programmer.

Re: Enterprise development: Its ok to say No!
by punchcard_don (Beadle) on Dec 16, 2003 at 22:45 UTC
    Well, this is the universal truth for all creative or problem solving jobs.

    Sometimes, like when the chips are down, you have to do a jgid job. But, say yes to everything, do a jgid job all the time, and your short-term relief will sooner or later yield to a reputation as a short-sighted hack.

    Sometimes, like when there's time and there's a lot riding on it, being a 'profi' will protect the comapny's interests and earn you a reputation for having professional principles. But a guy who always has to turn everything into a 'study' will quickly find himself labelled a slow moving dinosaur unsuitable for tasks requiring quick action.

    And there's everything in between for the 'Contractors'.

    Applies to any and all problem-solving or creative jobs - from engineers and programmers, to car mechanics and cooks.

Re: Enterprise development: Its ok to say No!
by Anonymous Monk on Dec 18, 2003 at 15:15 UTC

    "No I cannot do this. First off what you have there is a solution. I don't implement solutions. I solve problems. Come back to me and tell me what you want done, and I'll put together some proposals for you, but I certainly wont do what you've just asked until you tell me a lot more about the real problem at hand."

    What arrogance!

    OK, so you might be a hotshot programmer with a background in game theory, head of your local mensa chapter, but to presume that you have a monopoly on the production of solutions just reeks of elitism.

    Do you even admit the legitimacy of other professions?

      I found this thread very interesting. The replies I recieved interpreted my comments in many different ways: only a few that were on the exact wavelength that I was trying to communicate on, but pretty much all were worthy. But I have to say yours so completely missed the point that I feel obliged to respond.

      to presume that you have a monopoly on the production of solutions just reeks of elitism.

      Im afraid this is a false start. I dont claim to have a monopoly on solutions. I have no idea how to fix the air conditioning, or the lan, or the backup library, or the power plant, or the sales department, nor the finance department. I wouldnt even consider telling the lawyers how to do their job: not only am I from a country with a totally different set of laws and legal principles, but I dont even know the ones in my own country well enough to comment on them. However, insofar as the IT/IS systems that are used in my company I'm one of the few that knows them (or the trade in general) well enough to make intelligent decisions. (Sure there are others with similar skills, but I either work with them already, or they work for radically different parts of the company: as in a different country, or on totally different subject matter.)

      Do you even admit the legitimacy of other professions?

      Of course I do. As I said I wouldnt dream of telling the network guys how to fix the lan when it goes offline. But lets turn this around. Do they respect me? Is it respectful to go to a skilled professional and tell them how to solve your problems? Lets say the lawyers are working on something that has to do with me. Would it make any sense for me to go and tell them how and when to file their briefs? Would it make any sense to go to the finance department and tell them how they should account for things? Why should it be any different for me (us)? Why is it somehow ok for a lawyer to walk up to me and ask me to set up an "Excel database for storing real time data from these web pages?" Why should it be ok for someone to dictate to me how to implement a solution that I will be responsible for writing and maintaining? If someone came up to you and told you that you should write an order entry system in brainfuck would you do it?

      The whole point of this meditation was to point out that in a large enterprise enviornment there are lots of people who think they know enough computer stuff to tell development how they should do their job. (And the additional point that there are many people in our field who for one reason or another go along with it.) They want us to produce "excel databases" for mission critical systems. They want us to do all kinds of stupid things. Thats not our job. Our job is to produce systems that solve the business problem in a stable and efficient manner, and as cost effective as possible. If I grant the wish of the customer when the customer has asked for something stupid then all I'm doing is wasting my time, and the companies money. Which is most certainly NOT what a developer is for. We are there to produce tools to save the company money. Not to satisfy the whims of the less technically savy parts of the business regardless of the cost.

      An example: A long time ago I was too fresh to say no when a customer asked for a bizarre solution involving a lot of mission critical data stored in a zillion excel workbooks. I was too fresh to say "No way we are doing that. Well design you a database and a client to manipulate it, but im not touching your excel sheets with a ten foot pole." In fact I said something like that, but I allowed my better judgement to be overriden by the argument that "this was an interim solution, and we dont have any money for it anyway, so we just want something quick and dirty. After all we only can afford two days of your time." So I did the two days work and put together a JGID solution. And it worked. For a while. And then one day the team involved got a new teamleader, who in his infinite wisdom decided to change all the excel sheets around. Which of course broke the code I had written. So of course I then had to change the code. There goes another couple of days of development, and a few more in analysis and support. And because the solution uses excel sheets as though they were tables in a DB its horribly fragile. Despite far more hours of work than the project is worth there are still a whole host of things that can and do go wrong. Many of them requiring intervention by a developer. So now this project that was only going to be "two days of work" has literally mutated into weeks of work over the past few years. Never more than a few hours at a time, but all together in the range of a few hundred hours over the time the system has been run.

      If I had refused and forced the business to implement a proper solution I reckon it would have been between 40 and 80 hours work total, with about two or three hours maintenance by an operations team over a year. As it is the cost is far far higher.

      If theres arrogance involved here its in the patient that goes to the doctor and tells them what medicine to prescribe. No self respecting doctor will let the patient determine the cure, and in my opinion no self respecting developer should let the customer determine the solution. The customer defines the legitimate constraints just as the patient describes the symptoms. Just as a good doctor will include factors beyond the immediate symptoms, and will ferret out hidden symptoms and issues that the patient hasn't mentioned, so a developer should do the same.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        So it seems I misunderstood, sorry.

        I'm relieved to know that you do in fact respect other professions, at least I accept what you say, and on reflection I suspect that my misunderstanding was probably semantic; a different interpretation of the word "solution".

        To use your doctor/patient analogy, I was asserting that the patient has every right to say "I have halitosis, it's inhibiting my social life, and I want sweet smelling breath", whereas I would agree with what I now think you saying that the patient does not have the right to say "...and I want you to prescribe benzodiazepine."

        I know this post is way after the fact; but I hope that people can still derive some benefit from it.

        I have worked at a shop where the upper management (VP) was a former JGID programmer; and most of our Business Partners (we weren't suppose to call them "Users" or "Customers") were trained to ask for solutions.

        We tried for a long time to re-train the BPs into presenting their problems and letting us design the solutions; but it hadn't worked up until the point I left.

        I found it very difficult to say "no" in that situation; because when we did, we were "wrong" and had to do it anyway; or we were labeled "purists" and denigrated for not living in the real world where things had to get done.

        The business was pretty successful despite these drawbacks.

        What do you do in a situation like that? How do you convince the BPs that there is a better way?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://315028]
Approved by broquaint
Front-paged by broquaint
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (13)
As of 2014-12-22 20:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (130 votes), past polls