
Ask HN: Would you walk away from this? - danielovich
I have been asked to consult a company in how they should speed up their development process.<p>Today the application which in the end of it all is a web application, consists of a lot of old ASP classic code, a COM+ bridge for being able to function within a mix of a lot of different .NET libraries written in .NET 3.5 (CLR 2). COM+ acts as a bridge between the two technologies.<p>The teams cannot compile code inside the development tools, it can&#x27;t debug unless they do it with some obscure hacks and workarounds and it seems that no one is really in control of what is going on in the core code base and no one really want to touch the original code base to clean it up and refactor&#x2F;re-write it.<p>My concerns are really rooted in different aspects of the project.<p>The project has been like this for multiple years, i mean, the ASP code base is around 10-13 years old. There is nothing wrong with old technology I think but building on top of it for over 10 years was probably not a great idea.<p>Then someone has tried to build a gap between ASP and ASP.NET and I assume this is because of business-needs and also no one really wanting to get their hands dirty with a refactoring.<p>Why would a business do this ? Keep patching and re-patching old code instead of cleaning up and making things smoother and safer.<p>Not to talk about the effeciency of developers and teams.<p>I am frustrated, only 3 weeks in, and I am obviously not the only on whom has tried to figure this out, but everyone has just given up and said &quot;this is just how it is.&quot;.<p>Given those facts, would you engage or walk away ?<p>I just don&#x27;t like to walk away, but this is basically a big mess which in turn runs a multi million dollars business.
======
mswen
I would engage but not assume it will last very long. In fact I would do a
three pronged approach early on. 1) I would identify a particularly nasty
corner of the code base that could be sectioned off and improved in such a way
that everything that touches it will be easier to deal with. This prong is
your short-term easy win "we did something to make life better."

2)Develop a reasonably detailed plan for complete update and refactor within
.NET environment. This preserves the legacy, skills and domain knowledge of
the current staff.

3)Develop a broader plan for a green-field rewrite in a modern environment
with great developer tools, training and support.

My guess is that they will not take either of the more radical approaches but
you will have delivered consulting on what they can do to speed up their
development process. They might not like the implications of the answers and
at that point you can probably just walk away.

------
csixty4
"Consult" can mean a couple different things. Are you working as a contractor
just focused on improving the dev workflow? If so, there's not much I can
offer you other than to keep beating the drum and trying to get some attention
on the issue.

But if you were brought in as a proper "consultant", then you might be in the
perfect spot to address this. Companies like this bring in outside experts for
one of two reasons: either so they'll say exactly what the person hiring them
wants them to say, or so they'll be free of any political ties inside the
company and free to say what needs to be said. You'll already know if you're
the former.

You need to be the expert they hired you to be. See if you can arrange half-
hour interviews from developers on up to the top of the company about the
product, how it's developed, how it's sold, etc. Ask how development resources
are scheduled. Quantify the time lost to working with the development
environment.

Don't ask for permission to do these things. Tell them you'd "like to" or you
"need to".

Most importantly, propose solutions. Describe them as "bold" and "visionary"
for the upper management. Talk about cost savings in developer time and tools.
Talk about the extra time/cost of on-boarding new employees. Show Google trend
data and stats from job postings to show their pool of potential employees has
moved on to more modern development stacks, and the quality and quantity of
new hires is at risk.

Remember, you were brought in to say all those painful things people may
actually be thinking but don't feel they can say.

And if you can't get anywhere with anybody, that's your report right there. Go
right to the head of the company and say "I can't continue with the work you
hired me to do because your employees are not engaged enough or committed
enough to change. I was brought in to fix technical problems, but this is
cultural".

BE the expert. Be the one who can say all the bad things everybody is thinking
and walk out the door with a check at the end.

Edit: also, pay close attention to seren's answer. There are no mustache-
twirling villains here, just people trying to do their job day-to-day and not
get fired.

~~~
AnimalMuppet
To take this one step further: You don't have to decide whether to walk away.
You just say what they need (not want) to hear. Then you let them decide for
you whether you walk away (by how they receive what you say).

------
MalcolmDiggs
I'd engage if you're up for a long-term commitment. The good news is: the
problems you're experiencing are pretty standard; the bad news is: it's going
to be a slightly painful road ahead to crawl out of that hole.

You're not going to be able to fix _everything_ at once, there's going to be
some amount of triage necessary, so you've got to prioritize your concerns.
Figure out which changes give you the most bang for your buck. If you can
prove your value by making a few small strategic changes, leadership might
trust you to do bigger overhauls later on.

If it was me, my main concern would be that the engineers don't want to get
their hands dirty. That's a really bad sign. Perhaps the biggest change you
could implement short-term would be to flip that culture on it's head. Set
some team goals around testing-coverage %, and documentation-coverage %.
Encourage small teams to pick a small part of the codebase, refactor it, write
tests for it, and write documentation for it. Reward them heavily for every
little increase in coverage. Make sure they feel pride of ownership. Make sure
they know they're not responsible for 13 years of code...just their tiny
corner of it. The main goal is to stop the developers from tying their
perceived self-worth/value to _NEW_ features; that can lead to a "slap more
lipstick on this pig" mentality. You want them to feel like investing
time/energy in the current codebase is worth it.

Little by little your metrics will improve. Eventually the codebase will be
stable enough (and the team will be productive enough) that you'll be able to
say "okay, I want 3-5 developers to split off from the herd and start a
ground-up rewrite". And that's where the real fun starts.

------
seren
> Why would a business do this ?

If you are in charge of SW team, without too much SW knowledge, and you have
to deliver something in the next 3 to 6 months to you customer, you would
likely ask your architect/developers to do "same as previous product" but with
a single modification for the new feature. This is the risk-free solution for
the short term. Add to that that managers could change every 2 years, there
are no incentive to take a big risk in rewriting or upgrading the technology.
But this is also the boiling frog syndrome, in the long term you end up with a
mess, and if you are in a competitive environment you are getting too slow and
your company will be eaten alive. If you are relatively competitor free in
your niche market, this could somewhat work...

If you hope to achieve something, you need to have a least one supporter in
the upper management. It is still very possible that they are unaware how bad
the situation is (or they are but they don't care for the long term). So
you're first short term goal, should be to communicate clearly what is wrong,
and above all what it costs the company every quarter in term of time lost,
bugs, etc. And you should propose an alternate solution with some roadmap
(even long term one). "In X years, we will have moved to Z and it will allow
us to gain Y"

If you don't have at least one big ally, you'll never manage to have some time
or resource to improve the situation. (It will probably be easier to convince
some of your colleague).

So if you can't rally any ally in the next 3 months, or at least find
potential allies that are aware of the situation, walk away.

PS : Even if this looks ugly, there might have been sound reasons that led to
that mess. Every small decision in the past were maybe good for the time
being. So don't judge too harshly your predecessors. Especially if you need to
convince someone in upper management, that the decision he had taken 5 years
ago, was absolutely horrible. (And since you are new, that could a very
possible misstep)

Edit : if you have been hired to speed up the dev process, at least someone
has started to think that maybe something was wrong, so there is some hope !

------
mooreds
Can you see a light at the end of the tunnel? Does the business side of the
business understand how much technical debt has arisen? Is there a third party
solution that does 90% of what you need? Does the business need to keep
upgrading the app or can it end of life it? Are there subsystems you can
upgrade relatively easily that will have business benefit?

"Where there is muck, there is brass."

I would get all your concerns on the table with the person who writes checks
and present some alternatives and let them choose.

(I went through this a few years ago with a 11 year old java + gwt webapp and
had some success.)

------
mahesh_gkumar
I would absolutely engage... __IF __the senior management is committed to
changing the status quo and is ready to invest money and time into the effort
and is ready to make changes (including org changes) to make this effort
happen. I have been in countless situations like these and the only times I
have seen success is when the executive team is committed.

Also, don't expect anything drastic to change in 3 or even 6 months. 10-13
years old is a lot of time and the technical debt would probably be huge. If I
have to guess, you are probably looking at a multi-year multi-project effort.

------
gus_massa
1) Are they paying enough? Money is not the only motivation, but usually a
underplayed employment comes with other environment problems.

2) Some ideas that may be useful: "Getting Things Done When You're Only a
Grunt"
[http://www.joelonsoftware.com/articles/fog0000000332.html](http://www.joelonsoftware.com/articles/fog0000000332.html)

------
jf22
This seems like an awesome and career defining movement to overcome a worse
case scenario challenge.

