How to convince fellow developers that the in-house framework is no good

Question

Here's the story: I have moved to a new job 3 months ago. The development team consists of 5-6 people, with one lead developer. All of the projects here are "one-man-jobs", there are no tasks requiring teamwork, everyone works on their own.

Management wants us to use an in-house framework, so that the projects where there will be more than one people are involved, can go more fluently. One person was tasked with writing the framework himself a few months ago, and now I have been given the task to use this framework from now on.

Much to my horror the code is filled with eval()s, call_user_func()s, silencing operators (@), global state is all over the system through static methods, public fields, global variables, and singletons. The classes all begin with the same prefix (the FW's name), thus killing code-completion, and all the classes' filenames begin with 'class.', making it even more impossible to use automatic completion. The classes are basically used for namespacing purposes, with no sign of polymorphism and encapsulation. Lots of already provided functionality are reinvented, like file locking, and session handling.

I have strongly rejected using it. We have agreed to have a discussion about why this is bad, and what can we do to make it better. Beside me, two other people were on the meeting, the lead developer, and the colleague who wrote the existing framework.

I was pretty much devastated after that meeting. I have tried making solid arguments, and giving examples why things are bad, and how they should be done, to make it more safe, reusable, and maintainable. They sprung back like pingpong balls. One argument against using private variables, and getting rid of global state, was that we can easily "gunge in" (is that the correct word?) changes at the last minute, which is harder to do with proper encapsulation. They didn't understand why I want to get rid of the @ operator, that it silences everything, not just php's default error displaying, and it will be almost impossible to find bugs, if they happen in a @function, and they should handle errors, not silence them. One of them agreed with me, that yes, we should handle errors, but this is a small thing, and there are errors that you cannot expect. I agreed on the last part, and told them that yes, that is why you disable error reporting. They didn't understand why I would want to disable that, because then you won't see any errors. In fear, I asked if they have error reporting turned on, on production servers, and a very confident and resounding, "yes!" was the answer.

I didn't know how to argue after this, I proposed the idea of coming up with some made up task, and everyone should solve it in their own way, and then give a presentation about how, and why they did it, so maybe we can demonstrate our opinions more easily. Everyone agreed. The task we came up with is a very very simple CRUD task. After 30 minutes I realized that I have just given a death sentence to myself. For a very simple task like this, using a full-blown MVC system is overkill, the other guy will use the framework in question, and solve the problem with 5 classes, whereas I will use ~20 or something, since much of MVC's strength lies in separation, scalability, and maintainability. If I try to reason for unit testing, dependency injection, loose coupling, they will think I'm a bozo.

I have proposed using a freely available framework, such as Zend Framework, since it's already written, tested, used, whatnot. The idea wasn't exactly shot down, but the lead developer didn't like it, since it's hard to extend the functionality of already existing frameworks. I'm not sure how much of this is true, I have only used ZF for a month, I don't consider myself proficient enough in it, to vote harder for it.

A little background: I already have a pretty successful project behind me, it was on a very short deadline so I had the option of using my own stuff, so I'm not completely seen as the "random smartass from streets", but I haven't earned too much respect yet either.

How would you go about solving this situation?

Answer 1

As with anything, SHOW them you can do a better job or create something better.

There is nothing worse than someone who will just complain about something, or talk about "how they can do it better" but doesn't supply anything concreate in the form of a new framework.

Also remember that telling people about bad code, or lack of proper Object Oriented design means absolutely nothing to management. They care about deliverables, getting things done on time and making money. So if what is currently in place works for them, they aren't going to care that it's not done properly.

however, if you can create something that gets things done QUICKER, then they might start to listen to you.

Remember, SHOW IT, don't tell it.

Answer 2

Be professional. Bad code looses money.

Write a report from a business perspective and give examples of alternatives and routes to replacement. Make an analysis of the time/money that might be being lost.

Be pragmatic, if investment has been made in the existing framework, can it be improved? How? At what cost? What financial benefit?

No company wants to loose money or time. Write it up, send it around, see what happens. If the company is non-responsive to well thought-out arguments and information, ask:

is it the right one for you?

Answer 3

Extend the task. Make it an iterative process, so you can show better extendibility. Preferably in a way the FW doesn't provide for.

Sometimes, you have to accept that you're working with people who are too clueless to even understand the problems you're talking about. Experience and education do matter. Some people have neither, and just need a few more blown projects to learn from.

Answer 4

You need to learn the fine art of politics. Being the best coder does not mean you will make top bucks and will not get laid off.

Answer 5

Hmm. Sounds like a difficult situation, given that you have no seniority, and there seems to be little to none understanding of the techniques you would like to use (which is worse than shops that know they should do things like unit tests, but say they can't due to time, personnel and budget constraints).

There are good answers already suggesting productive ways of earning more standing, and over time putting up a fight for more quality (politely and professionally, of course). If you feel they're worth it, stay and try. If it doesn't work out, and you're permanently unhappy with the way work is done, leave.

Answer 6

How would you go about solving this situation?

Quit.

And your lead developer is a monkey if he superficially thinks "frameworks can't be extended" if he hasn't even done the legwork to backup that statement.

Answer 7

Hi

They do all seem to be out of step with you don't they ? I'd either fire you or counsel you along this lines:

Keep your mouth shut and your powder dry until you have earned the respect of your colleagues. You will earn this by turning in good code, not by persuading them that they are doing it all wrong. How can you propose to use a technology, Zend Framework in this case, in which, by your own admission, you are not proficient ?

After your quiet period start to spread your wings a bit. Look for, or make, opportunities to improve the framework in small ways before tackling big chunks of it. Take care not to set up meetings in future at which you demonstrate your own naivety. Identify a path from the situation you are in then to the situation you want to be in.

Regards

Mark

Answer 8

Trying to argue, about a code thats already there and the developer who wrote it being there can be a very tricky situation. It moves beyond technical discussion at that point.

You can also try the following 1. Try to show the performance pitfalls of the in-house vs public frameworks, if you have the time or bandwidth 2. Alternatively, try to use the Zend framework in your new project and have someone else who is onto a similar task try the in-house framework, with the "statement" that if the latter proves successful you will adapt to it and make the necessary changes yourselves. This may prove your point as well as keep you in good books of the others as well.

Answer 9

Time for a new job. That place sounds like pure poison. You will not grow as a developer there.

Answer 10

I would rather have ten developers producing crappy code that gets the job done than twenty world-class developers sitting around arguing about why it doesn't.

In the end, you could be the most brillent programmer alive, but if you don't produce, you're pretty much worthless.

So simply saying, take it in stride. You will garnish more respect through showing that you are willing to adapt to the environment and are making an honest effort to improve the quality of the code one step at a time.

Tread lightly and your day will come :)

Answer 11

The problem here is the same as anywhere. You're the new guy. You can't just walk in and say "Oh, hey, that project that you guys spent months writing? Yeah it's garbage, and we should scrap it and use something else instead." The management and developers have obviously spent a lot of time on it, and a company can't just throw out months worth of work unless it's fairly obvious it's a lost cause. In your case, it's clearly not obvious to anyone but yourself.

My suggestion would be to use the framework. With only a few months development behind it, odds are that it's not going to be overly complex. Buggy? Hell yes. A pain in the ass to use? You know it. You're going to experience frustrating bugs. But there are upsides.

You obviously know you're stuff. You're confident enough to take on management and the lead developers and give them your professional opinion. But don't let it go farther than that (unless you don't value the job). Take their framework and use your skills to improve it. It's not too hard to refactor out garbage like eval statements. Painful, yes, but not difficult. By improving the framework, you'll get more accolades and respect as other users see what you've done, and building/improving a framework is a task with it's own rewards. You will learn a lot (even if you've done it before).

Document everything you do. JIRA or another bug-tracker can help you there. Track every fix you make to the framework. After awhile, put together a report on it saying "this is all the crap I fixed". If it's not any more usable by then, use that data to make a case for Zend or something else at that time. More than that, focus on the technical limitations of obvious flaws of the framework that you haven't been able to fix or can't be fixed (e.g. "because we use eval to do X, our traffic capacity is reduced by y% over this other proven method").

Keep the pressure on, but do it professionally and don't get angry about it. They spent months building it. It might be crap, but it's their crap.

Answer 12

It seems (probably since most of you have developed individually until now) that you do not have any written in-house code standards.

A (partial) way out of this situation may well be to try to agree on 'good practices' for company code.

For some of the problems you mentioned above it should be easy to convince your colleagues of the merits of 'better' practices (most obvious examples: the variable naming, filename conventions etc...). It may help a little.

Try to iteratively improve the framework code itself (don't change a lot of it in a short time or you may find fierce resistance with the original author).

Answer 13

Do your job as best, as you can. Produce good code and don't give in; show them, that you can be more productive, by going your way. If you have solid proof, that you can do your job better, they will come to you and try to copy your ideas.

There is no sense in coming as a newbie to the rest of the team and saying: hey, I know better; change your old ways and come with me. No matter how right you are, they won't. The moment they see, that you produce less bugs and your code is more manageable, you won't need to convince them any more.

Software engineering is a great thing, you know. If you are right and better, just do your job and it will come out eventually :-) And, by the way, read this. It's a little more elaborate description of what I am saying by a much more experienced and known engineer ;-)

Answer 14

As the new guy you really haven't gained their trust in your technical expertise, and you won't until you roll up your sleeves and show them. Work with the bad framework, make improvements upon it. Some coders talk a good game but in the end they submit endless quick fixes. Show them your ideas in working code, and show that they are more robust, more adaptable to changing requirements, have fewer defects, and take the same amount of effort, if not less.

If, after six months you feel like it's going nowhere, I'd look around for a new job and this time interview them as much as they interview you. Make sure it's a company which practices the kind of day-to-day coding you want to do.