How lucrative is a career in Computer Science?

Cluedo Monopoly wrote: »

The project should be let fail i.e. slip the release date. And lessons should be learned. Burning out the QA/Dev teams is futile in the long run.

OT covers up the cracks i.e. poor management, poor estimation, lack of contingency, lack of automation, waterfall model etc

Even the best software releases late. Take the hit, learn from it.

A good manager will let that project fail and report why it will and subsequently why it did.

Ah.

The issue here is you think the manager is working for his team, not for the company.

This is the same logic as the people who think HR will somehow take your side against the company.

The correct action for a manager, a good manager, is to try to hit the release date, and do lessons learned.

The QA manager does not have the authority to "let that project fail".

Well places can operate like that for years. Unfortunately.

Cluedo Monopoly

OMM 0000 wrote: »

I think that's unfair. If your team are understaffed and the executive management refuse to increase the team's budget (or can't increase the budget due to financial issues), there's not much the manager or staff can do.

Also, if your team rely on another team's delivery, your fate can belong to them. Here's a real example:

A software company who use waterfall as their SDLC. A meeting is held and all the team managers (product management, development, QA) give their estimate on how long they need to get their work done.

Product management guesstimate they need two months to finish the specs.

Dev guesstimate they need four months to write the code.

QA guesstimate they need two months of testing before they can release.

So that's eight months in total.

In reality this is what happens:

Product management take three months.

Dev take six months.

The project is now a month late, and QA haven't even started.

The CEO has promised the product will be released in December, so QA are forced to work a lot of overtime to reach this date.

The project should be let fail i.e. slip the release date. And lessons should be learned. Burning out the QA/Dev teams is futile in the long run.

OT covers up the cracks i.e. poor management, poor estimation, lack of contingency, lack of automation, waterfall model etc

Even the best software releases late. Take the hit, learn from it.

A good manager will let that project fail and report why it will and subsequently why it did.

Jim2007 wrote: »

Actually in most cases it is, because it means that people are not get sufficient downtime to be at the top of their game when they are on the job. It's also why most Swiss firms require employers to take a three week block holiday once a year.

That's not strictly true some people especially creatives work better under pressure. But not everyone, and you can't do it forever or you burn out and start to make mistakes. Which is why if it becomes habitual in a companies management culture it's toxic.

In one place I worked I actually did a load of analysis on how the development teams were so worn out they were creating more bugs than the teams could fix. The curve was escalating in the wrong direction. They had a couple of crisis meetings with major clients, who were ready to drop the product over it.

beauf wrote: »

It's not like overtime is always a bad thing if it's well rewarded some people like doing it.

The problem is if it's not rewarded and expected.

Yeah I remember working for a multinational which had overtime available all the time (optional), and quite a few people loved doing it as it was double pay.

At the time I was gearing up for a round the world trip, so I took advantage of it as much as I could.

When you want to do the overtime, and you know you're being paid a lot for it, it's an entirely different mindset. You enjoy doing it.

That was 10 years ago and I haven't come back to Ireland yet :P

Jim2007 wrote: »

Your basic assumption is wrong. People do not behave in the way you assume.

When a manager know he will actually be held to the developer's guesstimate as you call it, he won't accept it nor commit to it, unless he is absolutely sure he can deliver.

Likewise if the CEO knows that he is facing a bill which he legally must meet of say a 100% overrun, he becomes a lot more realistic about what is willing to commit to.

It is not unusually for a Swiss business manager to double the estimate he gets from IT, just to be sure that he will not get caught short.

What goes on many US companies in particular is complete nonsense - everyone committing to a project plan that they know from the get go will not be achieved.

My basic assumption isn't wrong. I've been working in IT over 20 years, about 10 of those years in QA (multiple companies), and I saw the same thing over and over.

Even on a common sense level, obviously if QA receive the product close to the release date they are going to have to work overtime, otherwise the release date will need to be changed. You can't always change the release date.

I don't think it makes sense to keep applying the Swiss model to Ireland. Ireland is much closer to the US model.

beauf wrote: »

It's not like overtime is always a bad thing if it's well rewarded some people like doing it.

Actually in most cases it is, because it means that people are not get sufficient downtime to be at the top of their game when they are on the job. It's also why most Swiss firms require employers to take a three week block holiday once a year.

OMM 0000 wrote: »

I think that's unfair. If your team are understaffed and the executive management refuse to increase the team's budget (or can't increase the budget due to financial issues), there's not much the manager or staff can do.

Also, if your team rely on another team's delivery, your fate can belong to them. Here's a real example:

A software company who use waterfall as their SDLC. A meeting is held and all the team managers (product management, development, QA) give their estimate on how long they need to get their work done.

Product management guesstimate they need two months to finish the specs.

Dev guesstimate they need four months to write the code.

QA guesstimate they need two months of testing before they can release.

So that's eight months in total.

In reality this is what happens:

Product management take three months.

Dev take six months.

The project is now a month late, and QA haven't even started.

The CEO has promised the product will be released in December, so QA are forced to work a lot of overtime to reach this date.

Your basic assumption is wrong. People do not behave in the way you assume.

When a manager know he will actually be held to the developer's guesstimate as you call it, he won't accept it nor commit to it, unless he is absolutely sure he can deliver.

Likewise if the CEO knows that he is facing a bill which he legally must meet of say a 100% overrun, he becomes a lot more realistic about what is willing to commit to.

It is not unusually for a Swiss business manager to double the estimate he gets from IT, just to be sure that he will not get caught short.

What goes on many US companies in particular is complete nonsense - everyone committing to a project plan that they know from the get go will not be achieved.

It's not like overtime is always a bad thing if it's well rewarded some people like doing it.

The problem is if it's not rewarded and expected.

beauf wrote: »

I both agreed and disagree with you. Certainly there are factors outside of your control.

I think waterfall is blamed when it's often poor management. It might be that waterfall only works with strong management. That would be fair.

But if OT becomes normalised and habitual. Then it suggests dysfunction. That I would say is poor management.

The one common characteristic I find with projects that come in on schedule and those that don't is the people involved. Some people always bring projects in on schedule and some don't.

For IT projects there's a loads of common traits that tell you very early on, usually in the initial meeting of how the project will go.

Sure. In the example I gave, the problem is poor management, but it's not the QA managers fault (the person requesting the overtime), it's the managers upstream who gave lowball guesstimates and allowed their teams to miss the deadline.

So my point is your manager and you can be completely blameless for the amount of overtime you have to do.

There's another side to this this. Sometimes you end up propping up this poor management and poor project planning. By trying to deliver the impossible you, being the "can do" person, you become complicit in perpetuating such practice. You might actually be better walking away from it, and only attach yourself to well run projects. Let the other stuff eat itself.

Usually the people who keep creating these unrealistic projects can't see that it they who are causing the issues and thus are unable to change and fix it.

https://hbr.org/2018/09/too-many-projects

OMM 0000 wrote: »

I think that's unfair. If your team are understaffed and the executive management refuse to increase the team's budget (or can't increase the budget due to financial issues), there's not much the manager or staff can do.

Also, if your team rely on another team's delivery, your fate can belong to them. Here's a real example:

...

I both agreed and disagree with you. Certainly there are factors outside of your control.

I think waterfall is blamed when it's often poor management. It might be that waterfall only works with strong management. That would be fair.

But if OT becomes normalised and habitual. Then it suggests dysfunction. That I would say is poor management.

The one common characteristic I find with projects that come in on schedule and those that don't is the people involved. Some people always bring projects in on schedule and some don't.

For IT projects there's a loads of common traits that tell you very early on, usually in the initial meeting of how the project will go.

Jim2007 wrote: »

you or your manager must be incompetent if you have to do OT regularly.

I think that's unfair. If your team are understaffed and the executive management refuse to increase the team's budget (or can't increase the budget due to financial issues), there's not much the manager or staff can do.

Also, if your team rely on another team's delivery, your fate can belong to them. Here's a real example:

A software company who use waterfall as their SDLC. A meeting is held and all the team managers (product management, development, QA) give their estimate on how long they need to get their work done.

Product management guesstimate they need two months to finish the specs.

Dev guesstimate they need four months to write the code.

QA guesstimate they need two months of testing before they can release.

So that's eight months in total.

In reality this is what happens:

Product management take three months.

Dev take six months.

The project is now a month late, and QA haven't even started.

The CEO has promised the product will be released in December, so QA are forced to work a lot of overtime to reach this date.

Manach wrote: »

The downsides are the long hours, as upskilling is mostly left to yourself and some companies (Multi-Nats) expect unpaid overtime work when the need arises which can be often.

Well two things really, this only happens in countries where the work life balance is not respected, which tends to be the English speaking world and when it does happen it applies to other professionals as well.

For instance I worked in Switzerland for over 30 years and on average you might work say 20 hours overtime in a year, if that as a developer. Federal law makes it very expensive to have people working overtime. First of all OT of 125% up to 20:00 and 150% there after and at weekends must be paid to all staff including managers (and salary includes OT does not fly) and secondly all OT is considered approved unless the company takes active steps to prevent you from doing it.

The result is that if you are doing say a major roll out the only people there will be the people needed to do the task and only for as long as absolutely necessary. That usually means very few managers for instance.

From a career point of view regularly working overtime is a negative flag - you or your manager must be incompetent if you have to do OT regularly.

OT and in particular unpaid is just not part of the Swiss work life. Expats working for US multi nations are another story.

HamSarris

In 4 years time when satellites start falling from the sky and washing machines start attacking people, that will be Mr Fegelien's first week as a programmer

listermint

Jim2007 wrote: »

Nonsense, every business manager knows we have not “rewritten” any bad code since the benefits “refactoring” was explained to him

But who refactors the refactorers :P