[wernercd]

> > What is the hardest technical problem you have run into?

>I never seem to find a quick good answer for this.

Real easy: Overcoming technical debt/bad decisions of the previous group of programmers.

At my current company/position, our group basically replaced an outside company - two programmers. You name something you should do and they did it: Code in the behind, logic in triggers, plain text passwords, direct database access - bobby tables all the way down, etc.

When they were in charge, the company had ~4 customers... we are now rocking ~30 unique customers. Their fragmented codebase is unmanagable.

Keeping a train moving while replacing the engine and changing the wheels would be easier.

This doesn't include company culture, inter-company politics, other decisions, etc.

[cookiecaper]

This is not impressive. This is normal. When they say "What's the hardest thing you've done?" I would hope that if you are going to run with this, you explain why conventional maintenance/upgrades were so extraordinarily difficult in this case.

Every developer dreams of going greenfield. Ultimately, that's because it's harder and much more tedious to read code than to write it. If you start from scratch, you understand the whole stack/platform, everything is customized to your liking, and so on. That's great for you, but the company is usually stuck spinning its wheels for months while you push this rewrite down their throats.

It's also very easy to underestimate the depth of domain knowledge and accounted-for corner cases encoded in an old codebase. It looks easy at first, but it usually ends up taking at least months to reach feature parity with the old software, which usually also means that people will use both systems simultaneously, requiring data synchronization, etc.

The whole thing becomes messy, and by the time you're done, the "new system" usually isn't really all that improved over the old system. Systems get convoluted in the process of development, business needs demand quick shoehorning of something instead of thorough refactoring, etc.

Once in a while, a full rewrite is indeed justified, but it's much rarer than most people think.

Going in saying "Yes, my company needed a full rewrite" is an instant orange flag in my book, and thorough questioning would be needed to determine if this is an ongoing attitude problem where there's a reluctance/reticence to read other peoples' code. That portends laziness, a disrespect for colleagues, and a disrespect for the business's needs, which are rarely aligned with tying its developer labor up in a greenfield reimplementation.

[wernercd]

"This is not impressive" That's because I've given you a mile high description.

We have an outside consultant who does one thing: Fix businesses.

When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it.

While I understand and don't disagree with what you say - a full rewrite is normally not the answer - you haven't seen this codebase. Or the company structure.

We aren't exactly doing a "full rewrite"... it would honestly be easier in many respects - we are keeping the company functional while replacing large chunks.

Aka Keeping the Train Moving while changing the Engine and the Wheels.

This isn't JUST a code base issue. Or JUST a culture. Or JUST management. It's a combination of all those - and many more that can't be covered in 3 paragraphs.

I could talk for 8 hours - and scratch the surface - of where we are and where we need to be.

[cookiecaper]

>When he says this is the worst situation he's ever seen? I take it with a little more weight than I'd take someone else saying it.

I take it as a consultant emphasizing biases that favor his presence.

Anyway, the point of my comment was not to nitpick your specific situation, which I have no information about and obviously cannot speak about intelligently. Perhaps it is as extreme as you indicate. If so, my only suggestion would be to focus on the difficult problems rather than colorful characterizations of them. In an interview, the employer will know about its own problems, and may imagine your running the interview circuit and saying all the same kinds of things about them.

The goal is that as general advice for what to say when someone asks about technical accomplishments/pride, talking about the nightmarish situation you're coming from is first, trite, and second, a signal that you may not possess the cooperative qualities or the perspective to properly evaluate situations as they arise.

[wernercd]

I agree on all points - the consultant has his own objectives just like the owners and my manager.

Is it the worst situation EVER!...? Undoubtedly not... but its definitely twisted like a pretzel with problem layers on top of problem. But we also aren't "rewriting from scratch" - that would be too difficult. We are replacing pieces one at a time and breaking/fixing as we go.

I'm compensated enough for the stress and like the people and environment enough to offset the "overall situation".

But yeah... my main point was to say that moving a company from "old broken" to "new shiney fixed" while keeping everything working, adding new features, etc is, at the heart, the largest technical challenge I've faced.

Devil is in the details - and "spinning" it correctly without bad mouthing the company (Which I do like, otherwise I'd not still be there) and while keeping to that main point (upgrading a company) is... interesting.

Finangaling the finer words isn't my top skill :)

[pc86]

> Overcoming technical debt/bad decisions of the previous group of programmers.

This is often a gold mine, just make sure your interview doesn't become a discussion about how bad other programmers are.

[wernercd]

Absolutely. I try not to bad mouth the individual - because the two guys seemed like good people.

Secondly, programming - to a degree - is "art". My version of a masterwork is different than yours.

But the framework decisions? Lack of documentation? Lack of source control? No dev environment? etc. Decisions and foundational information that is demonstrably wrong and needs fixing? And what we have done/are doing/will do? THOSE are the things to focus on.

[ssttoo]

how about overcoming technical debt you created yourself in the past? :)