3 grammar, flow, edited for clarity and to be more concise
source | link

Actually, this is a very difficult question because there is no absolutely right answer. In our organization, I know that we have been putting better processes in place to help and weproduce better code. We updated our coding standards to reflect how we, as a group, write code. We, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all those processesthese checks and balances, yet we suffer from the exact same problem you do.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or proposedemand change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate intoin a situation where we are forced to into the conundrum of "do it right" or "do it ASAP" and almostASAP." Almost always this is the, we are forced to "do it ASAP" problemASAP."

As software craftsmen, developers, programmers, people who code for a job, almost always we tend -- it is our natural inclination to "do it right" naturally or strive for thatright." "Do it ASAP" is what happens when we work to survive, as most of us do. The balance is hard.

I always start with going to myby approaching executive management (I am Director of Software Development and an active developer in that group) andto defend the schedule, team and work being done. AtUsually at that point is where I get stuck withI'm told the customer has to have it now and it has to work. When I know there is no playroom for negotiation or give, I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customerscustomer's need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always thisThis is almost always OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse, and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the, current or past (or currently)mismanagement, bad development practices that led to poor code quality, or various other factors, it can become may be taking you on a death march. My

My opinion in the caseshere is to do your best to defend good code quality and best practices to help getstart pulling your company out of the trenches. If notthere isn't a single person iscolleague willing to listen or go to bat with management for the group, then you might have to choose looking for a new job.

If you are a good developer, this is easy to do these days. If you are the kind of developer contributing the problem directly against management, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some peoplea new job.)

In the end, real life trumps all and if. If you are working for a company that needs to sell what you are developing, then these are the dailyyou will encounter this trade-offs off daily. Only by trying to getstriving to achieve good development principles early on, I have I been successful at staying ahead of the code quality curve.

It is a constant battle at times. Over zealous softwareThe push and pull between developers and salesmen are what tend to get my group into trouble. Remindsreminds me of thea joke,. "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.  

Actually, this is a very difficult question because there is no absolutely right answer. In our organization, I know that we have been putting better processes in place to help and we updated our coding standards to reflect how we, as a group, write code. We have a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all those processes, yet we suffer from the exact same problem.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or propose change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate into a situation where we are forced to into the conundrum of "do it right" or "do it ASAP" and almost always this is the "do it ASAP" problem.

As software craftsmen, developers, programmers, people who code for a job, almost always we tend to "do it right" naturally or strive for that. "Do it ASAP" is what happens when we work to survive as most of us do. The balance is hard.

I always start with going to my executive management (I am Director of Software Development and an active developer in that group) and defend the schedule, team and work being done. At that point is where I get stuck with customer has to have it now and it has to work. When I know there is no play or give I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customers need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always this is OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the past (or currently), bad development practices that led to poor code quality, or various other factors, it can become a death march. My opinion in the cases is do your best to defend good code quality and practices to help get out of the trenches. If not a single person is willing to listen or go to bat with management for the group, then you might have to choose looking for a new job.

If you are a good developer, this is easy to do these days. If you are the kind of developer contributing the problem directly, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some people.)

In the end, real life trumps all and if you are working for a company that needs to sell what you are developing, then these are the daily trade-offs . Only by trying to get to good development principles early on, I have been successful at staying ahead of the code quality curve.

It is a constant battle at times. Over zealous software salesmen are what tend to get my group into trouble. Reminds me of the joke, "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.  

Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all these checks and balances, we suffer from the same problem you do.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or demand change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen. All sorts of little things can culminate in a situation where we are forced into the conundrum of "do it right" or "do it ASAP." Almost always, we are forced to "do it ASAP."

As software craftsmen, developers, programmers, people who code for a job -- it is our natural inclination to "do it right." "Do it ASAP" is what happens when we work to survive, as most of us do. The balance is hard.

I always start by approaching executive management (I am Director of Software Development and an active developer in that group) to defend the schedule, team and work being done. Usually at that point I'm told the customer has to have it now and it has to work. When I know there is no room for negotiation or give, I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customer's need to get it ASAP, but something will go and it will get pushed into another sprint. This is almost always OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse, and timelines are getting shorter, then you are in a different situation than what I describe. In that case, current or past mismanagement, bad development practices that led to poor code quality, or other factors may be taking you on a death march.

My opinion here is to do your best to defend good code and best practices to start pulling your company out of the trenches. If there isn't a single colleague willing to listen or go to bat for the group against management, then it might be time to start looking for a new job.

In the end, real life trumps all. If you are working for a company that needs to sell what you are developing, then you will encounter this trade-off daily. Only by striving to achieve good development principles early on have I been successful at staying ahead of the code quality curve.

The push and pull between developers and salesmen reminds me of a joke. "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go.

2 ++ readability with punctuation
source | link

Actually, this is a very difficult question because there is no realabsolutely right answer. I know atIn our organization, I know that we have been putting better processes in place to help and we updated our coding standards to reflect how we, as a group, write code. We have a very strong test/refactor/design/code loop. We deliver continually or at least attempttry to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, but givendespite all of thatthose processes, yet we suffer from the exact same problem.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go live-live expectations that are unrealistic or propose change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate into a situation where youwe are forced to into the conundrum of "do it right" or "do it ASAP" and almost always this is the "do it ASAP" problem.

As software craftsmen, developers, programmers, people who code for a job, almost always we tend to "do it right" naturally or strive for that. "Do it ASAP" is what happens when we work to survive as most of us do. The balance is hard. 

I always start with going to my executive management (I am Director of Software Development and an active developer in that group) and defend the schedule, team and work being done. At that point is where I get stuck with customer has to have it now and it has to work. When I know there is no play or give I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customers need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always this is OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the past (or currently), bad development practices that led to poor code quality, or various other factors, it can become a death march. My My opinion in the cases is do your best to defend good code quality and practices to help get out of the trenches. If not a single person is willing to listen or go to bat with management for the group, then you might have to choose looking for a new job. 

If you are a good developer, this is easy to do these days. If you are the kind of developer contributing the problem directly, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some people.)

In the end, real life trumps all and if you are working for a company that needs to sell what you are developing, then these are the trade offs daily trade-offs . Only by trying to get to good development principles early on have, I everhave been successful at staying ahead of the code quality curve. 

It is a constant battle at times. Over zealous software salesmen are what tend to get my group into trouble. Reminds me of the joke, "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.

Actually this is a very difficult question because there is no real right answer. I know at our organization we have been putting better processes in place to help and we updated our coding standards to reflect how we as a group write code. We have a very strong test/refactor/design/code loop. We deliver continually or at least attempt to. At the very least we have something to show the stakeholders every two weeks. We feel we are software craftsmen and morale is high, but given all of that we suffer from the exact same problem.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go live expectations that are unrealistic or change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate into a situation where you are forced to into the conundrum of "do it right" or "do it ASAP" and almost always this is the "do it ASAP" problem.

As software craftsmen, developers, programmers, people who code for a job, almost always we tend to "do it right" naturally or strive for that. "Do it ASAP" is what happens when we work to survive as most of us do. The balance is hard. I always start with going to my executive management (I am Director of Software Development and an active developer in that group) and defend the schedule, team and work being done. At that point is where I get stuck with customer has to have it now and it has to work. When I know there is no play or give I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customers need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always this is OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the past (or currently), bad development practices that led to poor code quality, or various other factors, it can become a death march. My opinion in the cases is do your best to defend good code quality and practices to help get out of the trenches. If not a single person is willing to listen or go to bat with management for the group, then you might have to choose looking for a new job. If you are a good developer this is easy to do these days. If you are the kind of developer contributing the problem directly, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some people.)

In the end real life trumps all and if you are working for a company that needs to sell what you are developing then these are the trade offs daily. Only by trying to get to good development principles early on have I ever been successful at staying ahead of the code quality curve. It is a constant battle at times. Over zealous software salesmen are what tend to get my group into trouble. Reminds me of the joke, "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.

Actually, this is a very difficult question because there is no absolutely right answer. In our organization, I know that we have been putting better processes in place to help and we updated our coding standards to reflect how we, as a group, write code. We have a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all those processes, yet we suffer from the exact same problem.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or propose change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate into a situation where we are forced to into the conundrum of "do it right" or "do it ASAP" and almost always this is the "do it ASAP" problem.

As software craftsmen, developers, programmers, people who code for a job, almost always we tend to "do it right" naturally or strive for that. "Do it ASAP" is what happens when we work to survive as most of us do. The balance is hard. 

I always start with going to my executive management (I am Director of Software Development and an active developer in that group) and defend the schedule, team and work being done. At that point is where I get stuck with customer has to have it now and it has to work. When I know there is no play or give I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customers need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always this is OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the past (or currently), bad development practices that led to poor code quality, or various other factors, it can become a death march. My opinion in the cases is do your best to defend good code quality and practices to help get out of the trenches. If not a single person is willing to listen or go to bat with management for the group, then you might have to choose looking for a new job. 

If you are a good developer, this is easy to do these days. If you are the kind of developer contributing the problem directly, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some people.)

In the end, real life trumps all and if you are working for a company that needs to sell what you are developing, then these are the daily trade-offs . Only by trying to get to good development principles early on, I have been successful at staying ahead of the code quality curve. 

It is a constant battle at times. Over zealous software salesmen are what tend to get my group into trouble. Reminds me of the joke, "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.

1
source | link

Actually this is a very difficult question because there is no real right answer. I know at our organization we have been putting better processes in place to help and we updated our coding standards to reflect how we as a group write code. We have a very strong test/refactor/design/code loop. We deliver continually or at least attempt to. At the very least we have something to show the stakeholders every two weeks. We feel we are software craftsmen and morale is high, but given all of that we suffer from the exact same problem.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go live expectations that are unrealistic or change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen that is unplanned for. All sorts of little things can culminate into a situation where you are forced to into the conundrum of "do it right" or "do it ASAP" and almost always this is the "do it ASAP" problem.

As software craftsmen, developers, programmers, people who code for a job, almost always we tend to "do it right" naturally or strive for that. "Do it ASAP" is what happens when we work to survive as most of us do. The balance is hard. I always start with going to my executive management (I am Director of Software Development and an active developer in that group) and defend the schedule, team and work being done. At that point is where I get stuck with customer has to have it now and it has to work. When I know there is no play or give I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customers need to get it ASAP, but something will go and it will get pushed into another sprint. Almost always this is OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse and timelines are getting shorter, then you are in a different situation than what I describe. In that case either through mismanagement in the past (or currently), bad development practices that led to poor code quality, or various other factors, it can become a death march. My opinion in the cases is do your best to defend good code quality and practices to help get out of the trenches. If not a single person is willing to listen or go to bat with management for the group, then you might have to choose looking for a new job. If you are a good developer this is easy to do these days. If you are the kind of developer contributing the problem directly, then it might be a good time to work on your skills. What I mean is if you are having a hard time following good code design principles, then you are contributing to the problem. If you are spending countless night fixing bugs in code you wrote then its a good indicator to start looking at some way to get ahead of that (like TDD for some people.)

In the end real life trumps all and if you are working for a company that needs to sell what you are developing then these are the trade offs daily. Only by trying to get to good development principles early on have I ever been successful at staying ahead of the code quality curve. It is a constant battle at times. Over zealous software salesmen are what tend to get my group into trouble. Reminds me of the joke, "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go even in very small doses. It does get better and it helps the overall project.