How do you deal with a company that has misplaced their trust in a developer?

Question

I've recently started working with a company that needs ongoing support for their site. They already have a consultant whom they seem very pleased with and have placed a great deal of trust in him.

Here's the thing. The "Web App" is a regular frankenstein of various systems using Access, FTP, DTS, ASP Classic and ASP.Net. I've only scratched the surface but here's a process I've discovered today. In order for some content that is regularly updated to be added to the web site a regular user will open up an Access application and begin entering information. This information is stored in linked tables living on the intranet MSSQL server. When the user is satisfied with the content and finalizes the content the Access application starts several DTS tasks which connect to the live (web) MSSQL server which has been exposed to the cloud and transfer records from the intranet db to the live db. The access app also grabs various image files and queues a task to FTP them to the web site. There's also some processes that require the user to copy/paste records directly from a linked intranet db table to the live linked db table through this Access application.

As if that weren't bad enough this system has been around for awhile so the DTS tasks, DB tables and a host of other entities have really confusing names like "UploadTask_Step2_Old" and "ArticleImages_bad". Many pages on the public site aren't properly sanitizing querystring values and even worse, it's currently broken and the 2 main developers just left.

Despite all of this from what I gather the owners of the company feel that their system works well and they're happy with it. My impression is that even though they have been hiring intern level developers at this point I feel that the consultant should have alerted them to the fact that their system was turning into a monstrosity. How do I convey to them that this consultant is either 1) intentionally pulling the wool over their eyes and not keeping them properly appraised of the health of their system or 2) he doesn't know any better?

I have some ideas but I know the SO community has some valid input to offer.

UPDATE

After a few weeks of explaining, suggesting and prodding it was becoming pretty clear they weren't going for the much needed changes anytime soon. I explained to them I wouldn't be able to help and took my leave. One of those "You can lead a horse to water but you can't make him drink" kind of things I suppose.

Answer 1

The best way here is to not make anything personal or assign blame to any individual.

They have their system and it works for them. Great. Quite often the only language that the owners speak is a financial one so proceed by showing them the risks of running their business on the current system.

If the cost of the risk multiplied by the likelihood of the risk is more expensive than fixing the problem then you should have no problem justifying that the system should be improved.

Oh, and let the owners come to their own conclusion as to who is to blame.

Answer 2

Wow. I worked in a place that was CREEPILY similar to what you describe. One difference; the company I worked at did NOT feel like the system worked well any longer, because they'd had some devs in working on it, and they had been complaining about the system for months by then.

My best advice: call a meeting with management. Describe to them what the system is doing, and describe exactly why it is bad and what is wrong with the system. Do not gloss over things, but don't spend an excessive amount of time on any one thing; make sure that they know that there are MANY things wrong with the system. Have examples on hand.

At the end of the meeting, tell them that the system is horribly unmaintainable, and then you're going to have insist that they do some very hard things: 1. Insist that the original developer who created this monstrosity never works on it again (and recommend that he never be let near a keyboard again in his life). 2. Tell them that their system is largely unmaintainable, and will not be able to be properly maintained or expanded for a LONG time (probably a year or two, depending on the complexity). 3. Tell them that they need to IMMEDIATELY get a large team (4 or more people, again depending on complexity) working on cleaning up the code. 4. Insist on a 100% raise (I am not kidding about this). If they refuse ANY of these things, give them two weeks notice.

I may sound strident about this stuff, but here's the problem: these types of systems are HELL to maintain and try to get untangled; these things are absolutely horrible. And while management won't see the amount of effort that goes into fixing the system, it WILL take its toll on your health and sanity. You deserve to get paid for this. One other thing; when you slip a schedule (and you will, because systems like that are impossible to estimate), management will give you crap for a long time. The only way to assure that you will get enough management buy-in to assure that this system will get fixed is to insist on all of the above items.

I should note that I've never seen any management team that has satisfied all of the above requirements; but I HAVE seen TWO very promising companies go completely down the drain, losing millions of dollars for their investors, for having systems like this and not taking all necessary actions to fix things. I will repeat that: TWICE I have seen VERY promising companies absolutely flush their prospects (and MILLIONS of dollars) down the drain by getting into a situation very similar to what you describe, and when the problem was pointed out to them, not doing enough to fix it.

Good luck. You're going to need it.

Answer 3

If the client is happy with what they have then, as the newcomer, you aren't going to be able to convince them otherwise.

The reality is that developer's don't set out to create monstrosities like that. Instead, they evolve over time due to constraints placed on them by the people paying the bills.

Considering the access front end, my guess is that either the person (s) making the updates were comfortable with access or at the time it was the best solution they had. This would explain the linked tables etc.

One option is to determine if a modern CMS would solve the problems and provide some benefit beyond what they already have. If so, show it and see if management likes it. In the meantime, fix the code you have.

Answer 4

I ran into a similar scenario a few weeks ago. It was a website that has been around for years, and has been maintained by quite a few different developers over the years. Consequently, it's a patch-work of code that begins with old asp pages and spans all of the .NET frameworks clear up to 3.5! At no point in time did the customer or the developers put the brakes on and say "Hey, we need to upgrade to the latest, greatest whatever," and consequently it is a maintenance nightmare. Sadly, the customer is under the delusion that their project is just fine, because they have one developer who has "pulled the wool" over their eyes. If said developer should suddenly leave the company or kick the bucket, they're going to be in a world of hurt!

However, I was in a convenient spot, because after learning what I did about the project, I was able to just step away. Let me be blunt about it, I didn't want my name attached to it in any way. Now, if the customer gave it to me and said "Fix it," then yes, I'd take it and do it.

This probably isn't what you want to hear, but unless your job or well-being depends upon it, sometimes it's easier to just let the customer wallow in their own mud.

Answer 5

You're playing with fire, so be really careful. Point out the problems, don't point the finger. Back everything up with understandable reasoning, because they don't understand it like you do. And you probably don't understand it the way they do.

Don't even once say "to make things worse...". Don't enter into the politics.

If they aren't listening then do yourself a favour and run away. Or at least make sure they know that you will if you don't get what you want.

Answer 6

I've been on the flip side of this coin. I've written systems that over time have grown into the monstrosity you describe. This being due to lack of prioritization, multiple independent developers, and unrestrained feature requests or automation.

In small businesses, particularly, rigorous software development standards are unheard of; and the best you can do is be honest about what you see and warn management of the consequences. Don't be complacent if they want to put off fixing the problems... it will cost everyone their sanity.

RO

Answer 7

What would you estimate the cost of fixing their system too be?

It sounds like an off the shelf CMS with some customization might fit their needs but what would it cost to set that up and migrate their current system over without any major glitches?

It's a tough sell to transition an old system to something completely new. It's also something that many many many companies have failed at doing one time or another.

Have you tried talking to the consultant and asking what their real opinions are? Maybe they tried to propose a change in the past and management was unwilling to take the plunge. You'll never know unless you ask.

Answer 8

The issue you face is that they've chosen and trusted this guy and that to critise him is effectively to criticise them.

You need to take a different tack and talk about the benefits of an alternative approach in a way which is of interest to management. I'd focus on:

1) Risk mitigation. You have one person who can get hit by a bus, take another job and you're in trouble. You need to highlight this risk and to come up with a mitigation strategy.

2) Competitive tendering. Without standardisation you can't competitively tender and you're beholden to one person.

3) Cost of enhancements. If the architecture is as bad as they say then each extra change is costing more than it needs to. Pick through past changes and try to find specific examples.

4) Make it clear that they're heading for a very expensive rewrite. You need to point out to them (and quantify realistically) the technical debt they're building up and the associated future cost. If they don't address the problem now they're going to ask for a change in a year or two and it's just not going to be possible in any sort of remotely cost effective manner.

The way I'd address it is suggest a review with a view to making some recommendations (nice and non-threatening) and use that to quantify some of these issues. Out of that come up with stanards to stop it getting worse.

Then I'd then start on a staged programme of sorting things out. Don't present it as a major thing, make it a series of small things - say start with standardising RDMS on one platform (so migrate all the Access to SQL Server). Then migrate the ASP to ASP.NET - maybe not all of it, just some key bits. Slowly over 12 - 18 months you can tackle off all the worst offences.

So in summary three main things:

1) Resist the temptation to point the finger. Everyone in there is complicit in what's happened so you can't blame one person without catching others in the blast.

2) Quantify it. Show them what it's costing them.

3) Talk about things they care about. Don't talk about the right way of doing it, tell them about cost and risk.

Answer 9

Now, that might be a bit late, but for record I would really approach this differently depending on how much of this system were in your sphere of responsibility. If you're kind of person who should be able to say something on this, then say and insist that you're responsible for anything yours. If that's all responsibility of other people, I would approach it as a nuisance you can't change, like the crappy neighborhood: either accept as it is or quit.

Answer 10

Not to be a fly in your ointment...

You recently started at the company, and have probably not had the time to really absorb the code. There may be strange things in the code, but there could be very good reasons for them. Not saying there are, but you should probably ask the guy. Just remember, one man's framework is another man's spaghetti code.

If you try and code review their superstar, it will probably go very poorly for you. I would just talk to him and see what his thought processes were. As for rewriting, that is almost never the best business option (not programming) unless your resources are nearly unlimited, which doesn't sound like the case. If the solution is scaling and not causing that much pain, pick and choose your battles and where to make changes in the existing code base.

Answer 11

If you want to convince the owners of the company that their software is bad, you better come up with a plan that proves to them why your way is worth more money to them.

This is the real world. Doing something "perfectly" is not directly proportional to the amount of money it makes. If you are a "professional" programmer then by definition you must realise that money is the only thing that is pushing from the top.

As an aside, I for one have renamed database tables to something not disimilar to MyTable_bad, I have also manually run imports and exports from systems because I just didn't have the time to write something to automate it. False economy, maybe, you have to be in that situation to make that call though, not as a new third party.

There is always a reason things are done a certain way. In hindsight it may be wrong, but the reason was probably sound or unavoidable at the time.

Answer 12

I have written things like that; temporary fixes to a problem that the business owners refuse to surrender, that grow and refuse to die. It is a valuable lesson. Never write something, no matter how trivial, that you don't want to support for the rest of your life.

That said, there are generally two ways to approach the problem. (the software is the problem. you will not be able to do anything about the developer, and should not try)

1. Do a professional pro forma that cost-justifies the replacement. If the break-even point is not within 3 months or so, just forget it. Bear in mind that this kind of thing will usually result in one or more people losing their jobs. (and it will never be who you think it should be. they pick which positions to eliminate, not you) That is how cost justification usually works. You may end up feeling some guilt over this.

2. One of my favorites is SOX and its brothers and sisters. If you truly believe that there are serious security flaws, and can prove it by citing reputable business (not programming!) publications and other sources, SOX can be your friend. Poor risk management practices can land executives in jail - not often, but it does happen. Establishment of liability can be an even scarier prospect. Be subtle and persistent and do not nag or whine.

Remember, you will be speaking to business people. You will need to speak their language, not yours. If you start to talk about design patterns or best practices or something similarly arcane to them, you will have lost your case immediately and permanently.