

Developers blog post: No, I won’t do it. It would not be professional. - koski
http://weblog.madebymonsieur.com/no-i-wont-do-it-it-would-not-be-professional/

======
Tyrannosaurs
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.

~~~
zeemonkee
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
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.

~~~
BCGC
"... at the end of the day everyone's there to make money for the business"

Really. It seems to me like everyone's there to make money for their
departments / business units / lines of business.

~~~
endtime
Well, my company has only has 4 people full time, so maybe my perspective
isn't representative. :) But I've had people who were writing code on a
temporary basis get frustrated when things didn't stick to the spec 101% or
when there wasn't time for them to follow all the software engineering
practices they read about in a book and felt like trying...I understand all
that stuff (I've been on both sides of the equation), but what bothers me is
when people are inflexible on principle, to the detriment of the business.

------
johngalt
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

------
jdietrich
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>

I'm not sure regulating software development is a great idea, but we need to
do something.

~~~
kenjackson
Quite arguably the most highly regarded professional industry we have,
medicine, regularly does quick fixes. Paramedics and ER doctors regularly do
"quick fixes" that will have to undone later. Their goal is oten to keep you
alive long enough so that the right thing can later happen. Because once your
dead, it's a lot harder to do the right thing by you.

I've also seen similar things done by civil engineers with respect to
transportation. Adding these bikes lanes isn't perfect, but until we get the
new trail built it will be the best way for bikers to get from A to B. This
just seems commonplace.

Likewise, if the client is needing to get a new auditing system in place to
comply with some gov't regulation, and you're saying, "We need to use IoC
containers here... I don't care if that means the client will be shut down,
not doing this means I will have to refactor a big chunk of the code in the
next release and I'm not doing it" seems a bit absurd to me.

It seems like being a professional IS about understanding costs and making
tradeoffs.

~~~
gaius
That's not a good analogy, since doctors don't generally "forget" patients
that the paramedics bring in. The situation for many developers is, first aid
is _all_ that you're gonna get no matter what the injury, good luck.

------
trunnell
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-
Pract...](http://www.amazon.com/Software-Estimation-Demystifying-Practices-
Microsoft/dp/0735605351)

------
mithaler
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.

~~~
kilian
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 ;)

~~~
msmith
Agreed. Technical Debt is a great metaphor for explaining these concepts to
non-developers.

[http://forums.construx.com/blogs/stevemcc/archive/2007/11/01...](http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-
debt-2.aspx)

Short-term technical debt can speed development, but like credit card debt, it
quickly accrues interest. If you let your technical debt accumulate, then
eventually you're spending all of your energy servicing the debt instead of
improving your software.

~~~
jsankey
It would be neat if there were some way to make this "debt" more visible to
non-developers. At the moment it could be easily forgotten (by non-developers)
after the initial deadline is hit, leaving no time to pay it back before the
next "crisis" emerges.

The hardest part would be having some way to quantify the debt. But you could,
at least, make a record of the corners cut, and make any accumulation
extremely visible to management. Does anyone know of anything like this?

~~~
ecaradec
(estimated time - implentation) time over the course of the project + an
interest rate. Older hacks tend to cause more hacks, so interest rate would be
necessary (and more scary, which is a good thing )

We could have a pretty accurate debt precision in time, that time could be
used to fix things ?

------
robotron
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
_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.

------
omouse
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>

Let's try and bring a bit more professionalism into the industry.

------
edw519
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.

~~~
azanar
_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.

~~~
j_baker
"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."

Generally speaking though, it's less a matter of reasoning with them as it is
a matter of finding the right buttons to push. Is it that their goals are
misaligned from yours? Phrase your response in terms of their goals; they
can't be too out of line if they need something from you. Do they not trust
you? Point out that they're going to have to trust you whether you do it your
way or theirs.

If they're being genuinely unreasonable and out of touch with reality and they
are completely unwilling to change their approach, I'd personally rather spend
my time finding ways to not have to work with them. Chances are they really
aren't though. They just have a different way of looking at things that you
can't meet without learning to think like they do a bit.

~~~
cdavid
But what if they don't trust you until you can do things that they ask ? The
difficult situation is people who do not trust you _and_ ask you to do their
own way until they do - not realizing that doing it their way is exactly what
prevents you from doing your job. It is fairly typical in my experience, but I
have not found a way to deal with it effectively.

------
ekidd
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
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.

------
aiurtourist
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.

------
jay_kyburz
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.

------
arethuza
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
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.

------
zeemonkee
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.

------
ecaradec
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.

------
jakevoytko
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.

------
dansingerman
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.

------
dedward
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.

------
known
If you're a developer saying _no_ is appreciated. If you're in management say
no _diplomatically_.

------
tophat02
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?

