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.<p>Yes too often developers are ridden over roughshod, but I think it's important to put the other side of things.<p>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.<p>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.<p>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.<p>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.<p>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.
Business guys response to this:<p>1. Tell the developer to cut whatever corner is necessary<p>2. Forget that he insisted on cutting corners<p>3. Complain that the next change is taking to long as well<p>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"<p>5. Fire the in-house developer for cutting corners<p>6. Post on the web how hard it is to find good developers
This is one of the many reasons why the software industry should be utterly ashamed of itself.<p>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.<p>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 - <a href="http://en.wikipedia.org/wiki/Therac-25" rel="nofollow">http://en.wikipedia.org/wiki/Therac-25</a><p>I'm not sure regulating software development is a great idea, but we need to do something.
Steve McConnell, in his book "Software Estimation: Demystifying the Black Art" [1] gives this advice (paraphrased):<p><i>Never give off-the-cuff estimates, no matter who is asking.</i><p>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.<p>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.<p><i>Never give off-the-cuff estimates, no matter who is asking.</i><p>[1] <a href="http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351" rel="nofollow">http://www.amazon.com/Software-Estimation-Demystifying-Pract...</a>
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.<p>But when a <i>client</i> makes a request like this, often unaware of what may <i>actually</i> 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.<p>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.
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.
3 hours and no one's posted the Software Engineering Code of Ethics that was written jointly by the ACM and IEEE??<p>Read it, learn it, follow it<p><a href="http://www.acm.org/about/se-code" rel="nofollow">http://www.acm.org/about/se-code</a><p>Let's try and bring a bit more professionalism into the industry.
I never say "No".<p>I just say, "Yes. And this is what it will cost you to do it right:"<p><pre><code> - 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.
</code></pre>
Note that "doing it wrong" or "doing it quick & dirty" are not options.<p>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.
I'm not sure author distinguishes well enough between different kinds of kludges. For me, personally, here are some non-negotiable issues:<p>1. Security.<p>2. Unit tests.<p>3. Budgeting for enough time to address pressing "technical debt."<p>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.<p>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.”?<p>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."<p>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.
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.<p><i>I will never name a variable horribly.</i> -- A great mantra until everyone on your team thinks AcquiredContentLockSerializationPolicyBeanFactory is a good class name.
It doesn't look like this will be a popular opinion but I think this attitude is totally unprofessional.<p>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.<p>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.<p>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.<p>Make the hack, save the day, then go back and clean up after.
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.<p>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.
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.
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 :<p>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.<p>Actually even if you get a yes you should probably give arguments against too, because sometimes we can miss a thing too.
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.
If the only reason for not doing something is that it is "unprofessional", then that is not a good enough reason in itself.<p>There are many good reasons why something "unprofessional" should not be done, but there will be specific details for that.<p>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.<p>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.
You can try all the tricks in the book to do things the right way - but in the end, what <i>really</i> matters is who pays the bills.<p>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.