How to save a young and dying project?

Question

I am posting this anonymously because I don't want to get into potential trouble.
I have a big problem.
I recently joined a team that is less than a year old. I have been here since a month in to the project started. The company structure looks like this:

• Owner (non-technical)
  • Project Manager (non-technical)
    • Lead Developer (Technical, but bad at it)

This project is a website using ASP.Net that the Lead Developer designed a horrible architecture for. You will have to take my word at it, but basically, the way we are required to build web pages is giving us 3+ minute load times on a single web page over VPN in Debug mode.

It has spiraled to the point where other coworkers agree that they spend more of their day waiting for pages to load than actual development.

Now the big problem is this. Project Manager does not know technology and admits it. He has specifically stated that he trusts the Lead Developer to make the correct choices on application architecture.

No one on the team knows what the Owners opinion would be, but everyone is afraid to make waves in this economy (myself especially).

What would you do?

Answer 1

This problem can be demonstrated to the project manager in very non-technical terms. Put your site in a browser window in front of the PM and ask him to play around with it for a while. After about two page loads, the lead developer should be called on the carpet, if things are as bad as you say.

The PM may not have the specialized development knowledge to understand why it's bad, but he can see for himself as a general website user that it is. Other sites showing similar information load in a fraction of the time of yours, and yours is loading over the local network from the server in the next room.

If this doesn't fly, then go to the owner. The owner's a money guy, but he'll very quickly be able to see that a slow website which nobody will visit == no money. Set up the same demonstration, and before the first page loads he should be calling BOTH the PM and the Lead on his much plusher carpet.

If you're worried about one guy making waves, then get more than one developer willing to voice their concerns. Honestly, in a company as flat as yours, if the product you are developing is a bomb, you are out of work whether you speak up or keep quiet. So looking at it that way, you have nothing to lose but a couple extra weeks or months with the company. If that's a problem, schedule some "dentist's appointments" and look for new employment before airing your concerns, so if you lose this job you start the next one Monday.

Answer 2

Assuming your statements are accurate, you have a Lead Developer who is incompetent and a Project Manager who is incompetent (at least to the degree that he can't asses the skills of the team). Fine. You have the exact same options as developers on every team everywhere in the world.

1. Do you job without caring for the health of the company.

2. Look for work elsewhere.

3. Make reasonable suggestions to the Lead, PM, and Owner and hope they get adopted.

You're free to do any combination of the above simultaneously.

If you want to aggressively insure the health of the project, you'll have to work with the other developers to come up with a new framework in your spare time and demonstrate to the rest of the team why it is superior and the old work should be ditched in favor of it.

Answer 3

I worked in a similar situation, where the lead developer who was actually a partner in the company had created the "core" of the software and with the exception of a close friend who worked directly with him, other developers were not allowed to touch the core.

The "powers that be" also created rules like each module could only have one database table, because it's cleaner that way. And resulting from that, existing drop downs were created by selecting "DISTINCT" from tables in the database, rather than having a separate table.

There were a number of bad patches floating around because the implementation team had to get the job done, and the product would not function out of the box. These patches caused as many problems as they fixed and were customized (hacked) for each install.

My approach was to take one small part of the spec that the core did not support and write a small, good, generic patch for it. Something that satisfied the implementation team, but was not as threatening as "We need to completely change our thinking". Due to the animosity between the implementation team and the core developers it took months to convince the implementation team that my approach was better than their hacks. But once once they saw that I would listen to them and implement additional adjustments to support them, they were delighted and on my side. It took another month for the lead developer to accept the patch, but once he did it really opened up communication between all of us about better ways to design other parts of the system.

It's never a short road to change people's thinking, especially if you need to keep a civil relationship with them. But if you approach it right, you can gain respect without insulting your boss.

Hope that helps!

Answer 4

Very simple answer and solution. It appears that everyone is aware of the problem. Thus, your going around pointing out the problem is of no value to anyone. In fact it just makes you look like a whiner. If you want to add value then you need to point out the solution and build up the business case for changing to your solution. Then you can point out the problem with a corresponding solution. A demo would also go a long way in proving your solution. Of course, this may mean doing work on your own time, but it all depends on how important it is too you.

Answer 5

First of all, I would strongly suggest that you make sure of your facts in that it is an application architecture problem and not something in the VPN configuration. I have seen poorly configured VPNs cause this exact issue. Do you know for certain that the app is that slow inside the office?

If you have ruled out the network, I would go with KiethS suggestion and have the PM pull up the page.

Answer 6

It sounds like the business, or at least the project is going to go under at some point soon. Short of quitting, I'd try to distance myself away from it as quickly as possible eg. volunteer/request work on other projects going. Hopefully over time, you'll be spending less time on this disaster, and more on other projects that have a chance of working. You don't want to be thought of as 'the guy that worked on the project that didn't work'. It's all about protecting your reputation.

Answer 7

Does the owner want a good product or not? I highly suspect that the answer is "Yes"...and therefore, you need to speak up. You need to document the current architecture and then (with good imperical data), show how the product does not meet up to proper performance expectations. You say that your co-workers all know it performs badly - well...what about the customer? What are they saying? Use a performance measurement tool and determine what is taking so long. Many tools will even go down to showing you how long each function call takes. From all of this data, you should have enough ammunition to go talk with your project manager and the technical lead about why things are not the way they should and how some major refactoring may be needed to get the product up to speed.

Then (only after talking to the PM and lead), this SHOULD be enough to start making some changes. If the PM isn't convinced at that point, then you need to decide if this is really a place you want to be. If so, then possibly a meeting with the owner. If not, get that resume ready.

Make sure you document everyting every step of the way.

Answer 8

In technical terms I do agree with the suggestions above. On the other hand, I feel that it is more like a relation issue rather than a technical one.

If you want to take the smooth route, talking to the lead developer will be a suitable choice. I would not talk in the office though. Having a coffee outside will make things a little informal and more relaxed.

If that does not work, you can try to talk to the PM and then the owner.

If none works, I suggest you looking for a new job.

Answer 9

Honesty - and as much tact as you can muster.

Start with the lead developer and work your way up if you have to. Try to engage the better sides of their personality - If you lead dev likes to solve problems / likes to save the day / likes to be efficient / etc. phrase the problem in that matter - It won't hurt to point out instances where they have had success in the past as additional motivation.

If you aren't making some waves you're probably dead in the water.

Answer 10

Would it be possible to bring the problems back to a level which are measurable and in a non-technical manner so that the project manager and owner can understand.

For example, you mentioned the slow load time of 3+ mins, I would assume that there is a performance requirement somewhere in the spec, something as simple as "page to be loaded within 1sec". Something like this is measurable and cannot be refuted. If the root cause of this problem is found to be the dodgy architecture, then project manager and/or the owner should be stepping in to force some changes.

If not, then you have a systematic problem in your company where the initial analysis was done poorly and there isn't enough process in place to catch these type of problems. Consider jumping ship!

Answer 11

Real men speak up without resentment or emotion. That is the trick.

The only valid reason someone might be cross with you for speaking up, is if you come across as resentful:

THE LEAD DEVELOPER HAS NO CLUE WHAT HES DOING. I knew this was going to happen, but no one listened to me blah blah blah.

where as

The code model is wrong because it is difficult to maintain and slow. We need to be strategic about this moving forward, and fix these two issues.

The former is a battle to destroy, the latter is a battle for peace, and in the long term will garner you the respect a person gets for being honest.

If the project lead takes this as an afront, which he certainly might considering he might get fired, then simply say,

Do not hold me responsible for things I was not responsible for implementing. I am just being honest.