Developers blog post: No, I won’t do it. It would not be professional.(weblog.madebymonsieur.com)
weblog.madebymonsieur.com
Developers blog post: No, I won’t do it. It would not be professional.
http://weblog.madebymonsieur.com/no-i-wont-do-it-it-would-not-be-professional/
20 comments
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.
It works both ways.
Absolutely 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.
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.
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.
"... 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.
Really. It seems to me like everyone's there to make money for their departments / business units / lines of business.
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.
I was just about to make the very same comment, but you've said it much better than I would have.
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.
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.
> 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.
What happens when you're not allowed to fix/improve/refactor the hack? Sometimes developers are assigned new tasks immediately.
Generally when you explain to people what you want to do but also agree to do what they've asked for they're relatively happy with the trade-off. My experience is that people aren't against things being done properly, it's only an issue when that gets in the way of what the feel really needs to happen.
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.
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.
Then the promise has been broken, you nag them about it, and the next time you use it as why you won't do it.
Never say, "You're lying" though. Instead say, "once burned, twice shy".
Never say, "You're lying" though. Instead say, "once burned, twice shy".
If you're a good politician, that may help you push the right buttons - but unless you can show concrete business damage because of the choices made, you are still likely on the nasty end of the stick. Nobody cares whether the developers are happy with the code - they care whether the code solves their problem or not.
What promise? The point was that the managers won't promise anything.
What promise? The point was that the managers won't promise anything.
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.
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.
"Sometimes"? That's like saying that SOMETIMES rain is wet.
[deleted]
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
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
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.
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.
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.
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.
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.
This isn't political or profit motivated, I'm not in the US. I'm thinking of doctors in the UK where profit and costs are generally not the primary concern.
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'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.
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.
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.
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.
>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.
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.
In areas that aren't as life-threatening as, say, structural integrity of buildings, non-software engineers cut plenty of corners too. Much of the "cheap plastic crap" you see on a Walmart shelf was designed by an engineer (or at least its manufacturing process was), often deliberately taking shortcuts that reduce quality and reliability to keep price down, because that's seen as an acceptable tradeoff in some markets.
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.
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.
It makes as much sense to discuss the professional ethics of the "software industry" as it does to discuss the professional ethics of the writing industry or the mathematics industry.
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.
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.
It's not unprofessional to make a compromise in order to meet a short term practical goal. It is highly dependent on the context and the type of short cut taken, but some quick fixes are simply the most pragmatic option.
Great engineers, even in other fields, aim for the best results using constrained resources. Compromise is a key skill.
Great engineers, even in other fields, aim for the best results using constrained resources. Compromise is a key skill.
architects also have every line and inch of their work inspected by people who get paid to find flaws.
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.
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.
>but we have killed people - http://en.wikipedia.org/wiki/Therac-25
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.
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.
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...
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...
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.
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.
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 ;)
You wouldn't believe how good a relationship with a client will be if they understand ehat you do ;)
Agreed. Technical Debt is a great metaphor for explaining these concepts to non-developers.
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01...
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.
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01...
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.
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?
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?
(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 ?
We could have a pretty accurate debt precision in time, that time could be used to fix things ?
Unfortunately, most of the time, we are not the decision maker, especially if the requestor is of high rank (either from internal or external user with ranked M - SM,GM,MD etc). Even though I explain this and that, in the end, they will just say "Can do? When will you deploy it?"
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.
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.
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.
Agreed. There's a difference between "ugly hack" and "blatantly unprofessional", and the OP makes it sound like the two are equal. In actuality, they are not and in fact, many times people mistake the former as a personal affront for the latter, claiming some moral high ground when there's none to claim.
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.
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.
It's certainly "case by case, every time", but in every case the first thing should be customer education. If your customer wants a feature done in an unreasonable timeframe, don't say yes, don't say no, educate your client how long it takes to properly implement the feature.
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.
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.
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.
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.
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.
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.
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.
I never say "No".
I just say, "Yes. And this is what it will cost you to do it right:"
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:"
- 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.
Most of the time, I'd argue that you can't really say 'No' at all. Not if you want a happy client. If you do say no, then you'll just end up delivering an end product that isn't exactly what the client wanted and didn't have that feature they requested. I can't imagine any situation where that results in a happy client.
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.
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.
Bingo! I say, "here are your choices; A> will get you this, B> will get you this, but not this... " etc.
"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!
"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!
You're working for better clients/managers than I am:)
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")
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.
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 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.
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.
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.
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.
"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.
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 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.
I agree with you in spirit. The worst place I ever worked had managers like this in spades (not sure if they had any other kind).
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" [1].
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.
[1] 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.
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" [1].
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.
[1] 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.
I have yet to work for a manager that knows the difference between the right solution and the "quick and dirty" solution. Estimate out what it would take to do it right and then tell them that's how long it will take to do the "quick and dirty" solution.
The answer is to maintain a documentable trail of what went into the decision. Make sure that the details of the discussion are in meeting notes, an email thread, etc. Absolutely positively do not agree to anything on just a verbal agreement.
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.
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.
I never say "No".
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.
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.
Can I work for you?
It's that unusual? Oh dear.
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 :-)
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 :-)
Could be worse. 40K~ish for an entry level game programmer. Few exits there as well :P
Try the telecom sector: ~20K €, entry level. It's almost stupid.
ditto
What if what you're being asked to do is ethically questionable?
Ugly code is not generally an ethical issue.
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.
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.
It is, because it's a direct conflict of interest between the one implementing the "ugly solution" and the ones who are later going to need to read it, debug it, refactor it, etc. Who are, in fact, most likely to be colleagues, in this context.
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.
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.
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.
Of course those people rarely ask for stupid things and when they do it tends to be obvious why it's necessary.
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.
I will never name a variable horribly. -- 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.
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
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.
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.
[deleted]
If you're a developer saying no is appreciated. If you're in management say no diplomatically.
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?
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.