In the software engineering industry, which do you think is more important: timely delivery or high quality delivery? By that I mean, would you do things in a "hacky" way for the sake of delivering to the client on time, or would you rather postpone the delivery because you need more time to get it done properly?
Which is better a car or a bus?
Which is cooler water or air?
Which is more important the lungs or the heart?

The amortized value of an employee is quality x rate.
A great company won't make you think of this question, they could take it on their behalf to prioritize quality versus quantity.

There's definitely a problem that you're trying to share, which has some more specifics and context to this question. Maybe for more help, you'll need to share more.
i have been in this situation...
i personally prefer to have some time at hand and do a proper job and not "hack" something...

i think it more depends on a specific task, i would ask for more time from the management if the time
to do a proper job is too little, if i get it then i do a proper job, if i dont then i would go with a hack...
which will cost more on the long run, but if thats is the time they give me then that is what they will
get, i can't make miracles...

i got response from the management once that, "the cost of the project is too little , just do it the
quickest way and get back to your other projects", so it depends on the management more, if
they can postpone the release of a specific project and how much it costs etc...
I add a third factor: quality, rate, cost. And as the saying goes, you can only pick 2.

I behave differently at work, from when I'm coding in my free time and posting on LebGeeks. I don't particularly enjoy it, but sometimes work simply cannot afford "the correct way". I have written half assed code that's used by several teams now, and I don't have the time/budget to work on improving them. People have developed crazy tricks around bugs in my software, we won't fix this unless we have a very good reason to.
arithma wroteThe amortized value of an employee is quality x rate.
That's actually true. But still, no matter how good you are, certain solutions require significantly more time to implement.
arithma wroteThere's definitely a problem that you're trying to share, which has some more specifics and context to this question. Maybe for more help, you'll need to share more.
Not exactly. But it has happened on several occasions that I was forced to do things that could have been done in a much better way.
rtp wrotewhich will cost more on the long run, but if thats is the time they give me then that is what they will
get, i can't make miracles...
This is exactly what I try to explain to the project manager every time. The good thing is that he is very understanding and knows that a bug which costs $100 now, will probably cost $1000 to fix when the project goes live. But eventhough he does understand that, sometimes he makes it clear that we cannot afford investing 3 days working on a feature when it can be done in a 4-6 hours the "hacky" way.
rahmu wroteI behave differently at work, from when I'm coding in my free time and posting on LebGeeks. I don't particularly enjoy it, but sometimes work simply cannot afford "the correct way". I have written half assed code that's used by several teams now, and I don't have the time/budget to work on improving them. People have developed crazy tricks around bugs in my software, we won't fix this unless we have a very good reason to.
We have all done that before, we're in the same boat my friend. But what really bothers me is that this is plain wrong by all means! It makes me sad to write a piece of code I cannot be proud of. And it makes me feel horrible when I see other colleagues with less experience adopting things I've done "the wrong way" as a pattern. And then I have to explain that this is a bad practice and they shouldn't be doing stuff this way, while in fact I did it myself :)
I don't know about software engineering, but in tech support, time is of the essence, and most people in Lebanon (no offense to anyone) don't seem to think abiding by agreed-to timing is a big deal.

I'm afraid it has to be both time and quality if you want to be worth your pay. From the biggest to the smallest, sticking to a time schedule seems to be out of the question in this country.

@Kassem, again, your job is definitely more pressuring than mine, but then again, to be doing that job and not mine means you're in a different league above mine, which means to earn a good rep, you'll have to do both.
I think that three additional variables needs to be taken into consideration in the product/service:
- Customer requirements
- Risk
- Priority

By prioritizing the tasks, one should be able to set the appropriate resources to deliver on time with good quality. Start with the risky items that could impact the final product and the customer satisfaction. But most importantly meet the customer requirements, then polish later on to increase quality. In the end quality is in the "eye of the beholder". the customer won't be happy if you deliver a product/service on time and in good quality but doesn't meet the main requirements.
Can I generalize by saying: when you have a delivery date you will have to sacrifice quality.
I do now know or heard of any software that was delivered on time, with the best quality, no bugs and no change requirements.
Any release cycle dictates the release in the minimum amount of bugs. This translated to the acceptable quality.
Your manager would be pushing for that, he has to make the release decision and prioritize the tasks.
So if a feature needs 3 days he would need a hack in 3 hours and it might make the next release.
This is a part of every software no matter how huge or how small.
It is the programmers responsibility to ensure the quality of his product, minimal adherence to standards and future proofing. It is not his job to just "get things done".
Some companies focus on just "getting things done", or worst, just getting the money in their pocket. These are places to avoid.
A programmer should alwasy push for quality ,but he should understand that there are other concerns in the world :) and subsequently have the ability and be willing to compromise and be flexible sometimes.
If you ask the questions to programmer, you will have programmer's answers. Ask it to managers, and you might have other answers...
jsaade wroteCan I generalize by saying: when you have a delivery date you will have to sacrifice quality.
I do now know or heard of any software that was delivered on time, with the best quality, no bugs and no change requirements.
Any release cycle dictates the release in the minimum amount of bugs. This translated to the acceptable quality.
I have to agree. My colleagues and I (the team I'm part of, to be specific) have got into the habit of sacrificing quality when delivery date is imminent, but we explicitly ask the Product Owner (project manager in non-scrum terminology) for enough time to refactor the "faulty" code in the next sprint. This is working fine for us, but in a perfect world we would rather avoid doing that all-together.
rolf wroteSome companies focus on just "getting things done", or worst, just getting the money in their pocket. These are places to avoid.
I know of a leading company that does exactly that. Ironically, most of its best employees have left over the past two years and are now my colleagues.
rolf wroteIf you ask the questions to programmer, you will have programmer's answers. Ask it to managers, and you might have other answers...
Very well said. Makes a lot of sense.
@kassem you are talking about netways?
@rolf you can do that as long as you are one person working on the project and probably more if you are freelancing
When you are part of a team you need to sacrifice to make it else you will always be the bottleneck.
Code quality should ideally be insured by the product owner you cannot leave it to individual programmers else you will find incoherent code and incompatible modules.
@jsaade: How did you know that?! Was it really THAT obvious? I guess Netways better start working on improving their reputation... :P
I think we are forgetting one major role that isn't usually filled in any company which is the test engineer.

Good quality starts from the earlier life cycle of any project.
When you include the tester during the requirement analysis phase, and if he starts working in parallel with the project manager and developer, he can start designing the test scenarios, and as soon as the developer submits an eligible piece of requirement coded, the tester can test and generate his test report, which obviously can shed a light on the real quality that will be perceived by the client.

... and the above cited company name isn't the worst ... believe me i have seen BIGGER and WORSE companies :P
jsaade wrote Code quality should ideally be insured by the product owner you cannot leave it to individual programmers else you will find incoherent code and incompatible modules.
Who would the product owner be? Can you give an example?
Sorry i meant Team Leader but was typing quickly :)
jsaade wroteSorry i meant Team Leader but was typing quickly :)
That's the kind of things that happen when you count on others to check your work. It is more efficient in the long run if you maintain quality of your work, as opposed to having someone else being paid to check your work and then come back to you with corrections, and force you to look into your work again (when you have already moved on to something else) to re-write it.
On the other hand it is a good way to learn new things from each other.
In the end, it is all in finding a working balance between working alone and relying on others.