Sometimes a contractor, who has been on lots of jobs and seen everything, can tell immediately that things are not going well. They can see a way out. And 6 months is a long time to watch the walls fall in around you.

I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time.

Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things.

So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid.

Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.

My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions.

A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability.

If you are good you can make improvements in the worst code base without having to change everything first.

> This gives you credibility and trust. Then make your suggestions.

Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.

I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.

Yes, working with shitty code is part of the job. You can't refactor if you can't read other people's code, no matter how bad it is. It's still code, and it probably does something in production that's needed.

Sure bad code that works is defensible in a cost analysis.

But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere.

Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain.

I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.

I agree that there are just plain bad code bases that aren't worth fixing. But my point was that a lot of us (including myself) have a tendency to immediately dismiss what our predecessors did without having made an attempt to understand the situation.

Let's just say, assuming that you are a rock star and everyone else can't code is a poor starting point. I have been on the receiving end of this attitude, and it's not pleasant. These people just come across as arrogant, and they look really bad when they screw up right out of the gate. Some humility goes a long way, EVEN IF YOU ARE 100% RIGHT.

That's exactly it, professional experience opportunity cost and what you spend time getting good at.

So it sounds like: you're a contractor (i.e. you are part of the most disposable group of people in the building), you have a fixed duration of work (presumably with an option to extend... but that's not a unidirectional option), as a group the contractors scope of work has been altered (from strategic to tactical), and your contract is almost up.

If this isn't what you signed up for and have other options, provide the customer of your intent to end the engagement when you have satisfied the term of the contract at 6 months (don't do it early, just give whatever notice is needed so you can end it on time). Don't assume that anyone there cares about your ideas on how to fix things or they would have asked you already.

One big caveat: if you're going through a 3rd party contracting company I've got some bad news for you... you probably never were there for the strategic work but rather to be a warm body to sit there and be billable so just put in your notice and move on. Worst case, you get offered more money to keep putting up with it (make sure it's a real increase... I'd go for at least 15-25%)... and if that appeals to you, enjoy some easy money riding it out for a bit longer.

Honestly, I'd probably get out. Some things just aren't fixable. I'm in a similar situation now and really weighing just finding a better place, but of course there are some complications.

Suggest some overall changes, which if they aren't taken seriously, increase your rate for the next six months?

I've approached the topic of changes, and been shut down each time. They've got so much on their plate, talking about design is the last thing they want to do apparently.

And yeah 'rate' at a large corporation is an intractable thing. My contracting company (I'm a partner) is billing through another contracting company, which is billing thru a billing company, which is contracting the client. The deal was, take this rate or take another job.

Which means, I've been looking constantly for another gig of this length or better. Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.

> Meanwhile feeling guilty about taking their money for turning their crank, instead of actually applying my skills.

The company agreed to (or set) your rate, they set the assignments, you've done due diligence in informing them of higher level issues, you have nothing to feel guilty about.

Things often have to hit some minima low point for larger changes to be considered. Hopefully they'll still have to resources to stay afloat while the change is enacted... but personally there may be little point waiting around for it unless you see an opening to where you can help at a higher level (and at a higher rate) and they're willing to accept it.

That's ... eerily familiar. Almost as if you were sat in the same team as me.