11 ms·

Developers blog post: No, I won’t do it. It would not be professional.

132 points by koski 16y ago

arethuza 16y ago
An important bit of context is missing - what is the application doing? If there is a safety element then yes it would be highly unprofessional, if this is something that is reporting the earnings of a large public company then yes, unprofessional. However, if the business impact of it going wrong is low (and there are plenty of apps in that category) then make the change and catch up with the docs and unit tests later.
- Tyrannosaurs 16y ago
  Absolutely. If I were writing embedded software for a heart monitor my standards would be very different to if I were knocking up a department intranet site for a division of a large corporation.
omouse 16y ago
3 hours and no one's posted the Software Engineering Code of Ethics that was written jointly by the ACM and IEEE?? Read it, learn it, follow it http://www.acm.org/about/se-code http://www.acm.org/about/se-code Let's try and bring a bit more professionalism into the industry.
johngalt 16y ago
Business guys response to this: 1. Tell the developer to cut whatever corner is necessary 2. Forget that he insisted on cutting corners 3. Complain that the next change is taking to long as well 4. Bring in another Dev as "consultant" to "help" who says "hey this code is crap, and this shouldn't have been done this way" 5. Fire the in-house developer for cutting corners 6. Post on the web how hard it is to find good developers
edw519 16y ago
I never say "No". I just say, "Yes. And this is what it will cost you to do it right:" - Projects X, Y, Z will all be pushed back 2 weeks. - Prerequisite Project <x> will have to come first. - <x> weeks overtime for <y> people = $z. - Joe and Mary will have to be pulled away for 3 weeks. - Interim solution <x> will only take 1 week, but <y> won't work. - We will need your top supervisor full-time next week. or, best of all: - We don't know. We need a project to find out. Note that "doing it wrong" or "doing it quick & dirty" are not options. People understand "this is what it will take" a lot better than "no". They also understand the trade-offs and sacrifices needed. Then they will work with you to make the best decision for everybody.
- modoc 16y ago
  You're working for better clients/managers than I am:)
- makmanalp 16y ago
  This is great advice. The best thing about it is that it dispels any notions that: a) the thing you're doing is simple b) it can be done quickly (which turns the situation from: "he won't get off his lazy ass and do it" to "i'm asking for way too much, and this is going to risk the project")
- Tyrannosaurs 16y ago
  A friend (in a completely different line of work) said that the reason that directors (he works in TV) liked him was that he never said no, he always gave them options. Yes you can have the helicopter for that shot you want but you'll need to lose this, this or this from the rest of the episode. It's a great lesson for most things in life.
- j_baker 16y ago
  I agree. Generally speaking, saying "I'm the developer, and I say this is wrong" is no better than "I'm the manager and I say do it now". I think the best approach is usually to say "I can do that, but understand that you're putting the next project behind to do this one". Granted, that won't change their mind. But you will have an excuse for being behind next time.
- azanar 16y ago
  I never say "No". I just say, "Yes. And this is what it will cost you to do it right" You have a number of "this is what it will cost you" options which will only work if the party you are negotiating with is reasonable. There are teams and managers out there who will happily assert that they can violate the laws of space-time in order to avoid making the sacrifices you'll tell them they need to make. Note that "doing it wrong" or "doing it quick & dirty" are not options. What if you are told directly to do it "quick & dirty," and you refuse? Is that not the same thing as saying "No"? Or by never saying no, do you mean never say no without providing what qualifications would turn it into a yes? What do you do about people you know will attempt to spin things later on to bolster their claims that they weren't advised of the costs ahead of time? In other words, what do you do about people who don't have an impeccable sense of ethics? It seems like you would need that before you could feel safe being this agreeable.
jakevoytko 16y ago
Always push back if something is wrong. If both parties are willing to meet halfway, it sometimes leads to a better solution (as a tradeoff between man-hours and functionality) than if one of the developer or the manager completely got their way.
deleted 16y ago
[deleted]
ekidd 16y ago
I'm not sure author distinguishes well enough between different kinds of kludges. For me, personally, here are some non-negotiable issues: 1. Security. 2. Unit tests. 3. Budgeting for enough time to address pressing "technical debt." If I can't address (1-3) properly, then my sustained development performance decreases sharply, and I provide less economic value. No thanks. Any organization which I can't educate about these issues will probably be a long-term loser, anyway. But client in the article who said, “Oh yes, the specification was wrong, but we need to do this right now. We cannot launch without. Everyone has it. It such a small change. It must be easy and fast to do.”? Usually, these requests are very easy to handle in a well-run development shop. Tell the decision maker, "Hmm. That's a 2-point feature. Let's see how it affects the schedule. We should be able to get that out tomorrow, at the cost of slightly more technical debt in module X." Developers need to be able to respond to last-minute changes. And you'll never get a complete, correct specification up front. So you need to learn to deal with changing requirements without wrecking the code.
- Tyrannosaurs 16y ago
  I'll negotiate anything, but I'll only do so with someone who has shown they really understand what's being traded off. Of course those people rarely ask for stupid things and when they do it tends to be obvious why it's necessary.
trunnell 16y ago
Steve McConnell, in his book "Software Estimation: Demystifying the Black Art" [1] gives this advice (paraphrased): Never give off-the-cuff estimates, no matter who is asking. Bosses and project managers tend to hold you to those estimates regardless of the caveats you give. Also, of course, an off-the-cuff estimate is very likely to be more wrong than a detailed estimate. Here's why this is relevant to the OP: by withholding your estimate until you've had a chance to give it enough thought, you relieve the social pressure that is created in the moment by the project manager or boss who is saying, "we must have it and it must be easy, can you do it today?" Just say, "let me get back to you," and follow up with a reasonable compromise that is healthy for the project and meets the business goal. Never give off-the-cuff estimates, no matter who is asking. [1] http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Pract...
zeemonkee 16y ago
This may be a huge motivation for people doing their own start-ups and side-projects. The continual compromises, crappy legacy code, spurious feature requests and unsavoury hack jobs of day-to-day business development spur developers to go off and do something on their own - even if it's just a weekend project on GitHub - so they can remind themselves that software development is a fun and challenging activity.
mithaler 16y ago
As a developer of custom business webapps, I have been in this situation many times and I desperately wish I could take this advice. Really, I do. But when a client makes a request like this, often unaware of what may actually be easy or fast or simple or consistent, I can't say no to it. Saying that we need to take more time to write tests and document it properly would likely come across as similarly unprofessional and reflect badly on the company. And the consequences are every bit as bad as you say they are: the code rots and becomes volatile and obnoxious to maintain. That's why it hurts to read this post--it feels so painfully true. I'm lucky in that at my company, my project managers are coders themselves who understand the programmatic constraints and the danger of software rot--but my clients usually aren't. I have no solution for this; it's a fine line to walk.
- SHOwnsYou 16y ago
  You need better PMs. A PM that can say no is a hugely valuable resource. My guess is that you either don't have PMs that say no or there is a really poorly structured chain of communication (ie - you have clients contacting more than just their PM for changes) which is changing the PM/Client relationship. It is largely about drawing a line in the sand. If you let your clients overrun you with requests, then they will keep doing it. Why wouldn't they? Get billed the same for more features? Sign me up. Luckily I have PMs watching out for me.
  - Tyrannosaurs 16y ago
    Any PM who won't say no at least until they've made sure that everyone has all the information to make a good decision isn't in the right job.
- kilian 16y ago
  The answer to this is educating your clients. This is an important part of running a company. You need to be able to tell your client in their language why something is hard to do. it's best to do this via metaphors or analogies concerning their profession. You wouldn't believe how good a relationship with a client will be if they understand ehat you do ;)
Tyrannosaurs 16y ago
Developers should absolutely push back and make sure that the person requesting the change has all the information needed to make a good decision, however they also need to understand that they, the developer, may only have part of the story and that they need to respect that the decision is coming from someone who may understand things that the developer does not. Yes too often developers are ridden over roughshod, but I think it's important to put the other side of things. In the same way that person may not understand the consequences of the dirty hack, the developer frequently will not understand the consequences of delaying the change. Unless the developer can honestly say that they understand the relevant part of the business better than person making the request, some humility and willingness to compromise and discuss is likely to be appropriate. For me the issue is not with doing the hack, it's getting the agreement that we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. That way everyone gets what they want - the fix is made in the timescales the business deem necessary and the developer isn't leaving a mess for future developers to have to clear up. Being a professional programmer in a commercial environment isn't about sticking rigidly to some definition of what's "right" (which will often vary from one developer to another anyway), it's about using code to fix real problems and provide real benefits in ways which are appropriate to the situation and balance all the variables. It's a variant of the old "good coders code, great coders ship". Being a great coder is about finding ways to meet everyone's needs.
- deleted 16y ago
  [deleted]
- zeemonkee 16y ago
  Shouldn't the business people in the organization also learn to understand the consequences to the company of poorly managed development processes and technical debt ? It works both ways.
  - endtime 16y ago
    Yes, and that's what Tyrannosaurs is saying. The article is what's one-sided - it doesn't seem to understand that (unless you work for e.g. 37 Signals) software is in service of the business, and at the end of the day everyone's there to make money for the business.
jdietrich 16y ago
This is one of the many reasons why the software industry should be utterly ashamed of itself. In other industries, it is a matter of professional ethics that you should never perform bodges or quick fixes, even if the client demands it. Architects do not allow themselves to be bullied into scrimping on foundations. Engineers do not build unsound structures if the client demands it. The fact that you'd need to say "it would not be professional" is proof that software development is not currently a profession. Qualified doctors and lawyers don't talk about professionalism much because it has been drilled into them during training and has become implicit in everything they do. Software failures can be every bit as costly and damaging as those in other industries; Usually our failures just cripple a business or leak confidential data, but we have killed people - http://en.wikipedia.org/wiki/Therac-25 http://en.wikipedia.org/wiki/Therac-25 I'm not sure regulating software development is a great idea, but we need to do something.
- Tyrannosaurs 16y ago
  Huh? Law firms have whole departments related to professional practice and it's a major topic among medics at conferences and elsewhere (you can take masters degrees in medical professional ethics). However I think it misses the point. Doctors will frequently give options which are not ideal. Patients are offered choices - do you want the surgery (which has risks) or would you like to try the drugs (which are less likely to work and have side effects, but there is less risk and the patient may just not want surgery) or do nothing (which will achieve nothing but the patient may not like the other options and wish to live with the condition). Similarly lawyers will frequently tell clients they shouldn't follow a course of action (a plea, filing a libel claim) to be over ruled. Being professional is providing all the information and giving the person the choice and then doing the best job you can based on their decision, it's not about some absolute right or wrong.
  - alxp 16y ago
    Yep, doctors have been complicit in creating the United States' for-profit healthcare system. If they live by a code of ethics that says "first, do no harm" then an objective outside observer would say they've not only failed miserably, they've actively worked to harm people who need medical care.
robotron 16y ago
This is nice and I completely agree with the sentiment. Do it where I work and you'll be out of a job. If you can afford to do that, go ahead - maybe you'll enact change.
- azanar 16y ago
  Do it where I work and you'll be out of a job. You might be out of a job anyway, even if you decide to go along. Companies do not fire people just for matters of insubordination, they fire people for budgetary reasons as well. If whatever change is pushed for costs the business millions of dollars because the lowly develop who said it was dangerous was right, that developer is still at risk of being fired. The only think that might save you is a culture which demands that companies be loyal to their employees at the expense of everything else. Everwhere else, obsequiousness isn't as safe as everyone thinks.
jay_kyburz 16y ago
It doesn't look like this will be a popular opinion but I think this attitude is totally unprofessional. Coders and managers should be working together to reach the same goals. They should trust one another. If a manager walks into your office and tells you he has an important presentation in 20 minutes, a critical feature was missing from the spec, I think the professional thing to do is whatever it takes for that important presentation to be a success. Why would you be ashamed if doing some dirty tricks in the code if the result is a big new client? You should be proud you were able save the day. This attitude reeks of "not my problem" syndrome where programmers only care about the quality of the code and not the overall success of the business. Make the hack, save the day, then go back and clean up after.
ecaradec 16y ago
Almost every time I implemented something where my guts said no was a disaster. Business types need to learn if we say no at first, insisting to get a yes is a really bad idea. Tech is not negociable, we aren't doing a deal at that point. Sometimes we are too tired to find detailed and convincing arguments why it's wrong and explain the little tiny details to convince you : Yes programmers should give options, and learn to works with business guys. Don't worry we know that lesson. But, we are all on the same boat and as scary as it is, you have to learn to work with us too ... If you get a no, try to understand why is it a no, but never try to change it to a yes. Actually even if you get a yes you should probably give arguments against too, because sometimes we can miss a thing too.
aiurtourist 16y ago
I always love developers that value their work enough to consider the Hippocratic Oath. The problem is that any oath attributed to a creative art such as programming will be subjective. I will never name a variable horribly. -- A great mantra until everyone on your team thinks AcquiredContentLockSerializationPolicyBeanFactory is a good class name.
tophat02 16y ago
Do this on one of my teams and I'll fire you that day. I KNOW it's a hack. That's why I asked you to hack it in! Do you think I like it?
dedward 16y ago
You can try all the tricks in the book to do things the right way - but in the end, what really matters is who pays the bills. I'm not underestimating the value of good code, or the damage BAD code can do in the long run - but in the typical business case the code exists to serve the business. If you push back too hard just because you want to do it 'right' - you might very well find yourself replaced with someone who delivers faster.
dansingerman 16y ago
If the only reason for not doing something is that it is "unprofessional", then that is not a good enough reason in itself. There are many good reasons why something "unprofessional" should not be done, but there will be specific details for that. Quick dirty hacks are often why the software industry is great. If you can fix something quickly that can save your business you're a hero. If you obstinately refuse to fix a problem _only_ because doing so would be unprofessional, at the expense of your product, your business, your colleagues jobs, you're an idiot.
known 16y ago
If you're a developer saying no is appreciated. If you're in management say no diplomatically.

132 points by koski 16y ago

An important bit of context is missing - what is the application doing? If there is a safety element then yes it would be highly unprofessional, if this is something that is reporting the earnings of a large public company then yes, unprofessional. However, if the business impact of it going wrong is low (and there are plenty of apps in that category) then make the change and catch up with the docs and unit tests later.

Tyrannosaurs 16y ago
Absolutely. If I were writing embedded software for a heart monitor my standards would be very different to if I were knocking up a department intranet site for a division of a large corporation.

omouse 16y ago

3 hours and no one's posted the Software Engineering Code of Ethics that was written jointly by the ACM and IEEE?? Read it, learn it, follow it http://www.acm.org/about/se-code http://www.acm.org/about/se-code Let's try and bring a bit more professionalism into the industry.

johngalt 16y ago

Business guys response to this: 1. Tell the developer to cut whatever corner is necessary 2. Forget that he insisted on cutting corners 3. Complain that the next change is taking to long as well 4. Bring in another Dev as "consultant" to "help" who says "hey this code is crap, and this shouldn't have been done this way" 5. Fire the in-house developer for cutting corners 6. Post on the web how hard it is to find good developers

edw519 16y ago

I never say "No". I just say, "Yes. And this is what it will cost you to do it right:" - Projects X, Y, Z will all be pushed back 2 weeks. - Prerequisite Project <x> will have to come first. - <x> weeks overtime for <y> people = $z. - Joe and Mary will have to be pulled away for 3 weeks. - Interim solution <x> will only take 1 week, but <y> won't work. - We will need your top supervisor full-time next week. or, best of all: - We don't know. We need a project to find out. Note that "doing it wrong" or "doing it quick & dirty" are not options. People understand "this is what it will take" a lot better than "no". They also understand the trade-offs and sacrifices needed. Then they will work with you to make the best decision for everybody.

modoc 16y ago
You're working for better clients/managers than I am:)
makmanalp 16y ago
This is great advice. The best thing about it is that it dispels any notions that: a) the thing you're doing is simple b) it can be done quickly (which turns the situation from: "he won't get off his lazy ass and do it" to "i'm asking for way too much, and this is going to risk the project")
Tyrannosaurs 16y ago
A friend (in a completely different line of work) said that the reason that directors (he works in TV) liked him was that he never said no, he always gave them options. Yes you can have the helicopter for that shot you want but you'll need to lose this, this or this from the rest of the episode. It's a great lesson for most things in life.
j_baker 16y ago
I agree. Generally speaking, saying "I'm the developer, and I say this is wrong" is no better than "I'm the manager and I say do it now". I think the best approach is usually to say "I can do that, but understand that you're putting the next project behind to do this one". Granted, that won't change their mind. But you will have an excuse for being behind next time.
azanar 16y ago
I never say "No". I just say, "Yes. And this is what it will cost you to do it right" You have a number of "this is what it will cost you" options which will only work if the party you are negotiating with is reasonable. There are teams and managers out there who will happily assert that they can violate the laws of space-time in order to avoid making the sacrifices you'll tell them they need to make. Note that "doing it wrong" or "doing it quick & dirty" are not options. What if you are told directly to do it "quick & dirty," and you refuse? Is that not the same thing as saying "No"? Or by never saying no, do you mean never say no without providing what qualifications would turn it into a yes? What do you do about people you know will attempt to spin things later on to bolster their claims that they weren't advised of the costs ahead of time? In other words, what do you do about people who don't have an impeccable sense of ethics? It seems like you would need that before you could feel safe being this agreeable.

jakevoytko 16y ago

Always push back if something is wrong. If both parties are willing to meet halfway, it sometimes leads to a better solution (as a tradeoff between man-hours and functionality) than if one of the developer or the manager completely got their way.

deleted 16y ago

[deleted]

ekidd 16y ago

I'm not sure author distinguishes well enough between different kinds of kludges. For me, personally, here are some non-negotiable issues: 1. Security. 2. Unit tests. 3. Budgeting for enough time to address pressing "technical debt." If I can't address (1-3) properly, then my sustained development performance decreases sharply, and I provide less economic value. No thanks. Any organization which I can't educate about these issues will probably be a long-term loser, anyway. But client in the article who said, “Oh yes, the specification was wrong, but we need to do this right now. We cannot launch without. Everyone has it. It such a small change. It must be easy and fast to do.”? Usually, these requests are very easy to handle in a well-run development shop. Tell the decision maker, "Hmm. That's a 2-point feature. Let's see how it affects the schedule. We should be able to get that out tomorrow, at the cost of slightly more technical debt in module X." Developers need to be able to respond to last-minute changes. And you'll never get a complete, correct specification up front. So you need to learn to deal with changing requirements without wrecking the code.

Tyrannosaurs 16y ago
I'll negotiate anything, but I'll only do so with someone who has shown they really understand what's being traded off. Of course those people rarely ask for stupid things and when they do it tends to be obvious why it's necessary.

trunnell 16y ago

Steve McConnell, in his book "Software Estimation: Demystifying the Black Art" [1] gives this advice (paraphrased): Never give off-the-cuff estimates, no matter who is asking. Bosses and project managers tend to hold you to those estimates regardless of the caveats you give. Also, of course, an off-the-cuff estimate is very likely to be more wrong than a detailed estimate. Here's why this is relevant to the OP: by withholding your estimate until you've had a chance to give it enough thought, you relieve the social pressure that is created in the moment by the project manager or boss who is saying, "we must have it and it must be easy, can you do it today?" Just say, "let me get back to you," and follow up with a reasonable compromise that is healthy for the project and meets the business goal. Never give off-the-cuff estimates, no matter who is asking. [1] http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Pract...

zeemonkee 16y ago

This may be a huge motivation for people doing their own start-ups and side-projects. The continual compromises, crappy legacy code, spurious feature requests and unsavoury hack jobs of day-to-day business development spur developers to go off and do something on their own - even if it's just a weekend project on GitHub - so they can remind themselves that software development is a fun and challenging activity.

mithaler 16y ago

As a developer of custom business webapps, I have been in this situation many times and I desperately wish I could take this advice. Really, I do. But when a client makes a request like this, often unaware of what may actually be easy or fast or simple or consistent, I can't say no to it. Saying that we need to take more time to write tests and document it properly would likely come across as similarly unprofessional and reflect badly on the company. And the consequences are every bit as bad as you say they are: the code rots and becomes volatile and obnoxious to maintain. That's why it hurts to read this post--it feels so painfully true. I'm lucky in that at my company, my project managers are coders themselves who understand the programmatic constraints and the danger of software rot--but my clients usually aren't. I have no solution for this; it's a fine line to walk.

SHOwnsYou 16y ago
You need better PMs. A PM that can say no is a hugely valuable resource. My guess is that you either don't have PMs that say no or there is a really poorly structured chain of communication (ie - you have clients contacting more than just their PM for changes) which is changing the PM/Client relationship. It is largely about drawing a line in the sand. If you let your clients overrun you with requests, then they will keep doing it. Why wouldn't they? Get billed the same for more features? Sign me up. Luckily I have PMs watching out for me.
- Tyrannosaurs 16y ago
  Any PM who won't say no at least until they've made sure that everyone has all the information to make a good decision isn't in the right job.
kilian 16y ago
The answer to this is educating your clients. This is an important part of running a company. You need to be able to tell your client in their language why something is hard to do. it's best to do this via metaphors or analogies concerning their profession. You wouldn't believe how good a relationship with a client will be if they understand ehat you do ;)

Tyrannosaurs 16y ago

Developers should absolutely push back and make sure that the person requesting the change has all the information needed to make a good decision, however they also need to understand that they, the developer, may only have part of the story and that they need to respect that the decision is coming from someone who may understand things that the developer does not. Yes too often developers are ridden over roughshod, but I think it's important to put the other side of things. In the same way that person may not understand the consequences of the dirty hack, the developer frequently will not understand the consequences of delaying the change. Unless the developer can honestly say that they understand the relevant part of the business better than person making the request, some humility and willingness to compromise and discuss is likely to be appropriate. For me the issue is not with doing the hack, it's getting the agreement that we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly. That way everyone gets what they want - the fix is made in the timescales the business deem necessary and the developer isn't leaving a mess for future developers to have to clear up. Being a professional programmer in a commercial environment isn't about sticking rigidly to some definition of what's "right" (which will often vary from one developer to another anyway), it's about using code to fix real problems and provide real benefits in ways which are appropriate to the situation and balance all the variables. It's a variant of the old "good coders code, great coders ship". Being a great coder is about finding ways to meet everyone's needs.

deleted 16y ago
[deleted]
zeemonkee 16y ago
Shouldn't the business people in the organization also learn to understand the consequences to the company of poorly managed development processes and technical debt ? It works both ways.
- endtime 16y ago
  Yes, and that's what Tyrannosaurs is saying. The article is what's one-sided - it doesn't seem to understand that (unless you work for e.g. 37 Signals) software is in service of the business, and at the end of the day everyone's there to make money for the business.

jdietrich 16y ago

This is one of the many reasons why the software industry should be utterly ashamed of itself. In other industries, it is a matter of professional ethics that you should never perform bodges or quick fixes, even if the client demands it. Architects do not allow themselves to be bullied into scrimping on foundations. Engineers do not build unsound structures if the client demands it. The fact that you'd need to say "it would not be professional" is proof that software development is not currently a profession. Qualified doctors and lawyers don't talk about professionalism much because it has been drilled into them during training and has become implicit in everything they do. Software failures can be every bit as costly and damaging as those in other industries; Usually our failures just cripple a business or leak confidential data, but we have killed people - http://en.wikipedia.org/wiki/Therac-25 http://en.wikipedia.org/wiki/Therac-25 I'm not sure regulating software development is a great idea, but we need to do something.

Tyrannosaurs 16y ago
Huh? Law firms have whole departments related to professional practice and it's a major topic among medics at conferences and elsewhere (you can take masters degrees in medical professional ethics). However I think it misses the point. Doctors will frequently give options which are not ideal. Patients are offered choices - do you want the surgery (which has risks) or would you like to try the drugs (which are less likely to work and have side effects, but there is less risk and the patient may just not want surgery) or do nothing (which will achieve nothing but the patient may not like the other options and wish to live with the condition). Similarly lawyers will frequently tell clients they shouldn't follow a course of action (a plea, filing a libel claim) to be over ruled. Being professional is providing all the information and giving the person the choice and then doing the best job you can based on their decision, it's not about some absolute right or wrong.
- alxp 16y ago
  Yep, doctors have been complicit in creating the United States' for-profit healthcare system. If they live by a code of ethics that says "first, do no harm" then an objective outside observer would say they've not only failed miserably, they've actively worked to harm people who need medical care.

robotron 16y ago

This is nice and I completely agree with the sentiment. Do it where I work and you'll be out of a job. If you can afford to do that, go ahead - maybe you'll enact change.

azanar 16y ago
Do it where I work and you'll be out of a job. You might be out of a job anyway, even if you decide to go along. Companies do not fire people just for matters of insubordination, they fire people for budgetary reasons as well. If whatever change is pushed for costs the business millions of dollars because the lowly develop who said it was dangerous was right, that developer is still at risk of being fired. The only think that might save you is a culture which demands that companies be loyal to their employees at the expense of everything else. Everwhere else, obsequiousness isn't as safe as everyone thinks.

jay_kyburz 16y ago

It doesn't look like this will be a popular opinion but I think this attitude is totally unprofessional. Coders and managers should be working together to reach the same goals. They should trust one another. If a manager walks into your office and tells you he has an important presentation in 20 minutes, a critical feature was missing from the spec, I think the professional thing to do is whatever it takes for that important presentation to be a success. Why would you be ashamed if doing some dirty tricks in the code if the result is a big new client? You should be proud you were able save the day. This attitude reeks of "not my problem" syndrome where programmers only care about the quality of the code and not the overall success of the business. Make the hack, save the day, then go back and clean up after.

ecaradec 16y ago

Almost every time I implemented something where my guts said no was a disaster. Business types need to learn if we say no at first, insisting to get a yes is a really bad idea. Tech is not negociable, we aren't doing a deal at that point. Sometimes we are too tired to find detailed and convincing arguments why it's wrong and explain the little tiny details to convince you : Yes programmers should give options, and learn to works with business guys. Don't worry we know that lesson. But, we are all on the same boat and as scary as it is, you have to learn to work with us too ... If you get a no, try to understand why is it a no, but never try to change it to a yes. Actually even if you get a yes you should probably give arguments against too, because sometimes we can miss a thing too.

aiurtourist 16y ago

I always love developers that value their work enough to consider the Hippocratic Oath. The problem is that any oath attributed to a creative art such as programming will be subjective. I will never name a variable horribly. -- A great mantra until everyone on your team thinks AcquiredContentLockSerializationPolicyBeanFactory is a good class name.

tophat02 16y ago

Do this on one of my teams and I'll fire you that day. I KNOW it's a hack. That's why I asked you to hack it in! Do you think I like it?

dedward 16y ago

You can try all the tricks in the book to do things the right way - but in the end, what really matters is who pays the bills. I'm not underestimating the value of good code, or the damage BAD code can do in the long run - but in the typical business case the code exists to serve the business. If you push back too hard just because you want to do it 'right' - you might very well find yourself replaced with someone who delivers faster.

dansingerman 16y ago

If the only reason for not doing something is that it is "unprofessional", then that is not a good enough reason in itself. There are many good reasons why something "unprofessional" should not be done, but there will be specific details for that. Quick dirty hacks are often why the software industry is great. If you can fix something quickly that can save your business you're a hero. If you obstinately refuse to fix a problem _only_ because doing so would be unprofessional, at the expense of your product, your business, your colleagues jobs, you're an idiot.

known 16y ago

If you're a developer saying no is appreciated. If you're in management say no diplomatically.