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.
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 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.
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.
But if we're honest with ourselves I think we have to admit that this is our fault. Why does the pointy haired boss even know about the "quick & dirty solution"? We always talk about how much better other engineering disciplines are, "you don't see bridges falling over every time someone makes a new model of car!" we say, but why is this? It's at least partially because no engineer offers a "quick & dirty" option for making bridges. They never say "well, we could use this material and skip all these steps to get done in 1/10th of the time for 1/5th of the cost but it's probably going to fall over" .
This is the key point. Of course for bridges purchasers are going to want the cheapest and fastest thing they can get. They aren't given an incomplete solution as an option so that's why they don't ask for it. If we want things to change in our industry we have to do what the GP suggested. Don't mention non-solutions, aren't you an engineer (at least partially, I know many of us think of ourselves as artists)? In fact, if a manager says "lets just do this quick & dirty" you should take that to mean that they still want a completely correct solution that just doesn't address some of the requirements (e.g. "handle email quick and dirty" might mean leaving out SSL).
>What if you are told directly to do it "quick & dirty," and you refuse?
This is the place where they shouldn't know this term. It shouldn't exist. No one asks a bridge builder for "quick & dirty" they ask for cheaper & faster. So the bridge maker considers all the possibilities that still leave a completely working bridge and answers based on that.
The bridge builder recognizes that no one is asking him what is the cheapest/fastest way to possibly make something that looks like a bridge. What good would that do anyone? We also need to understand that no one is asking us for what we mean by "quick & dirty". Are they going to expect it to fail 70% of the time? No? Then what they're actually asking for is a correct solution but they want it fast, cheap and without unnecessary frills.
 I have no doubt that some joker will find an example on the internet of exactly that happening. When you do, understand that you've found the exception that proves the rule, not that refutes the point.
You might still be stuck "doing it wrong" or "doing it quick & dirty" but you've got enough CYA material not to be the scapegoat.
Really? I expect to hear No (clarification: I am a project manager/ geek herder). That's fine. I don't need my developers to be wasting time working out convincing arguments and workarounds to requests - I trust that they want to be helpful and if they are saying no, there's a good reason. Hell, assuming I am on top of stuff, I can figure out what the reason is - and in the rare occasion when I can't, I just ask.
I am here so that my developers don't have to worry about this shit.
Yeah, if your PM is not shielding you, you can try that approach above - at least it makes you not look obstructive. However, people burn out doing that after a while, especially when they have to explain this stuff to people who don't want to understand them. In which case a simple "How does this compare with my current top priority X?" is generally sufficient.
The average HNer would probably gouge their eyes out rather than work for me. I am in academia - we think 65K is a good salary. No big exits here :-)
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.
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.
So what do you do? I say: Get the client to say 'No' for you.
Getting people to understand the trade-offs and sacrifices for what they might consider a "quick 'n easy" feature is the name of the game here. You've got to flesh out all the assumptions that they have when making such a request so that they understand what the impact is on schedule, budget, and code.
But what they still don't understand is why Projects X, Y, and Z will have to be pushed back for 2 weeks or why Joe and Mary will have to pulled away for 3 weeks just to do this "quick", "simple" thing. At this point, what I usually do is spec out the entire feature (front-loading all the mockups, copywriting, etc) on the spot or in a meeting immediately following. The reasoning is that "If you want this feature tomorrow, then it has to be designed today." And well, practically speaking, you can't implement it by tomorrow if you don't know what you need to do yet anyway and, worse still, you'll build the wrong thing if you don't at least discuss it in some detail with your client first.
If the feature isn't important enough to spec out in detail now, it's not important enough to be done by tomorrow.
In my experience as a solo webdev freelancer (so take it for what it's worth), clients usually see my point and give in when they realize that we're trying to compress about a week's worth of back and forth emails, phone calls, and let-this-idea-sink-in time into about an hour--sometimes even realizing that they don't really know yet what they want.
"Quick and Dirty" is still an available choice, but I warn them thoroughly of the drawbacks and risk.
Basically, if you wanna pay me, I'll still do it your way, but I will also provide ample warning, oftentimes in writing. Few/no people will still choose the bad way, due to the warning.
If their "Q&D" choice is just going to lead to certain disaster, then no, I write off that business as not worth my reputation or frustration, entirely.
But after my explanation(s), I've never had a customer choose the lousy way, and they always accept my explanation and guidance. It's all in the pitch!
Ethics are another matter entirely, and it really depends on your own reputation and how you want to protect it -vs- bringing home the bacon.
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.
It works both ways.
The reason I posted from the position I did is that too often in these discussions there is the assumption that the programmer understand the business well enough to make the call which in my experience is false.
The reality is that in these situations you have two people each of whom understand part of the problem. Simple black and white declarations of right or wrong by either party are unlikely to result in an optimal solution to the whole problem.
Really. It seems to me like everyone's there to make money for their departments / business units / lines of business.
In my experience, these requests that initially seem unreasonable will often have a very reasonable explanation. If you take the time to understand the motive, then will often be able to find some alternate solution that satisfies both the business and the developer needs.
What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
If you come up against people who really just won't listen I tend to make a note of the fix, log it as a bug and include it in the next round of bug fixing, the next bit of quiet time or whatever. Alternatively include the refactoring into the estimate the next time I'd have to do significant work on that module.
Two other points while I'm rambling:
Always make sure that the refactoring is genuinely necessary and not just polishing. Some developers like "perfect" solutions but often this results in over engineering and significantly increased timescales. The key question I find useful is "am I coding for a specifically stated requirement or probable edge case or am I extrapolating to what I think might be useful / needed in the future?". I'm with Kent Beck on code only for what you specifically need today.
Secondly, only real issue with this approach I've outlined is if someone micromanages your time so heavily that you can't do any of that AND they won't listen to reason. In that instance you might want to consider your options but I've only ever once been in that position.
Never say, "You're lying" though. Instead say, "once burned, twice shy".
The promise that you'd get time to do the fix. Which didn't happen. That was how I read:
> > we'll do the quick hack, but only if we're then allowed, in the very short term, to make the fix properly.
>What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
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
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.
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.
I'm specifically thinking of a case a friend was talking about. A woman presented with a certain condition and said she didn't want surgery or drugs. The friend had to explain the options and that medically most effective interventions tend to fall into one of those categories but living with the condition was also an option.
I don't know what the woman decided but the "professional" course of action wasn't about efficacy or cure, it's about understanding that there are needs beyond those which are "technically" best.
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.
This is the core essence of it. Professionalism is communicating and offering transparency, while adapting to, essentially, the real world.
When I hear the "give me an unmoving specification and I yield to no change" crowd, I envision them essentially as technicians.
Heck, even in areas where there are life-threatening issues involved, engineers often only "do it right" on the few things that are either mandated or seem particularly likely to cause serious injury that'd leave them liable. The cookie-cutter McMansions you see probably aren't going to spontaneously collapse on their occupants, but they aren't going to last 100 years with minimal maintenance either, because a lot of corners were cut compared to what "doing it right" would've looked like.
Lawyers and sofers, of course, are in the writing industry. That doesn't imply that you should follow your state bar association's code of ethics or the Tanakh when you write a shopping list, especially if you aren't actually a lawyer or Jewish. Ad copywriters, screenwriters, and administrative assistants are also in the writing industry.
As for the mathematics industry, it includes carpenters, mechanical engineers, ath professors, and cryptologists.
Mathematical failures and writing failures can be every bit as costly and damaging as bridge failures. (Mathematics failures can cause bridge failures.) Here in Argentina, the abortion law accidentally forbids abortion in the case of rape unless the rape victim is mentally disabled, apparently due to a missing comma, and some judges who were looking for any possible excuse to punish abortionists, obviously.
Software development should never be a profession. There are certainly professions that need to do software development, such as embedded control systems engineering, like what failed on Therac-25. But regulating software development makes as much sense as regulating the practice of literacy.
Great engineers, even in other fields, aim for the best results using constrained resources. Compromise is a key skill.
engineers would get sued into infinity if they built unsound structures.
it's a real slippery slope into pretentiousness, when as a profession there's no actual minimum code or governing authority.
Are you working on a radiation dosing machine? If you are (or you work on aircraft control systems or nuclear power plant safety systems, etc), then a completely different set of requirements and processes apply. If not, however, it's corrupting to bring such examples up in the context of someone making some trivial tool.
>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
Doctors often essentially wing it: They have to think on their feet and act quickly, and often apply essentially "hacks" where the inputs are not all known (many uses of drugs were essentially discovered by doctors who prescribed it for unrelated conditions, eventually leading it to be tested and actually certified for that purpose). Architects regularly have to adapt plan to new conditions, quickly.
Though of course what an architect does is far more structurally fixed than software -- again the analogy falls apart.
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.
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.
You wouldn't believe how good a relationship with a client will be if they understand ehat you do ;)
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.
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?
We could have a pretty accurate debt precision in time, that time could be used to fix things ?
The reality is that the "fine line" is the more reasonable and correct approach. It's case by case, every time. If there was a black-and-white rulebook, Joel Spolsky, Jeff Atwood, or Patrick Mackenzie would have blogged about it by now.
Not educating clients is the worst thing we can do as software professionals.
Why do most people not ask for a house with a rushed foundation or frame? Because most people know that that's asking for serious issues later.
Why do most clients ask for key software for their business rushed out the door and delivered ASAP, sans testing and without proper spec? Because most don't know that they're asking for serious issues later.
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.
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.
Read it, learn it, follow it
Let's try and bring a bit more professionalism into the industry.
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.
Of course those people rarely ask for stupid things and when they do it tends to be obvious why it's necessary.
I will never name a variable horribly. -- A great mantra until everyone on your team thinks AcquiredContentLockSerializationPolicyBeanFactory is a good class name.
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.
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.
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.
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.
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.