Fog Creek Software
Discussion Board

Am I being unreasonable?

I am currently the only developer of a services company. The business we're in forces us to have a great deal of internally developed tools, and I ended up being hired to maintain those tools.
They're written in lots of different languages, so I decided to migrate them to a J2EE environment. This would make maintenance and the future development of the applications a lot more easy.
Unfortunately, it's almost impossible. The older staff at this company were scared shitless upon my arrival. They saw me as a threat and are currently blocking all my efforts at doing anything
worthy. Instead of developing a full-blown J2EE application, I had to keep myself happy with a couple of servlets that don't even get used regularly. The current IT manager is simply unable to
change the current state of things. He literally has no power whatsoever, and when I try to go up the chain of command I get blocked. Since I am a newer worker I don't know many people here
and the older guys always get to the bosses first and manage to turn things around.
    Basically, although I was touted as an extremelly important hire by the company, I am doing nothing worthy and more importantly I am not doing anything usefull to the company. I spend
the days surfing the web and feeling angry.
    I feel I have no support from upper management because they simply don't understand the issues at stake and so chose to side with the people they know better. I also feel that this will not
improve. Either the company blows up or things will be like this forever (there isnt a chance in the world of the company going under. We do make a LOT of money).

    My question is: would it be unreasonable to leave the company now? Should I confront them first and give them a chance to change things (after all, it's in their interest) or should I just leave for the first decent oportunity that shows up?

I guess this post is more to vent my rage than to ask for advice, but any answer would be welcome.

Friday, March 28, 2003

Don't stick in a job you hate.

You have complete control over the tools, yes? Then migrate them. Don't support, or improve the existing tools - if anyone has a problem tell them to get your new version. Hold your ground.

Mr Jack
Friday, March 28, 2003

There are as many different ways of doing business as there are businesses, and it takes time to understand the business culture of a new company. I would recommend you don't try to change how the company does their business until you fully understand how things work. That is the only way you will earn their respect for your opinion. And who knows if you'll change your mind in the mean time.

Other than that, it sounds like a really bad idea to rewrite things that (I assume) already work just because you happen to know J2EE.

Big B
Friday, March 28, 2003

I'll be more specific on the technical details:
We have about 100 users. Right now they are using a mix of Visual Basic, Access and PowerBuilder apps. Right now our help-desk is simply overwhelmed with all the configuration issues that those applications cause. Even though we use the same Windows image on each computer we always manage to have problems with configurations and database connections and whatnot.

By migrating things to J2EE we would centralize everything and the only app the client machines would need was a browser.
And there's even the ethical side: the company had already planed this, but internally things are so fragmented that anyone can change the technical development of the company. I see us using these apps forever just because those individuals feel threatened by the web.

Friday, March 28, 2003

l would move on, possibly for reasons that aren't very important to you.

First, you mention that the company makes a LOT of money. Such companies depress me: if they make money no matter what, what difference do you make?

My ideal company is doing ok, and would do better if l do a great job.

Second, it sounds like you don't respect your colleagues. That's poisonous for you and for them. Don't waste your life blaming them, and don't brood over why you ought to respect the fact that they have figured out how to make money with tools and processes you abhor.

Go find a place where you look forward to seeing your colleagues every day!

Reginald Braithwaite-Lee
Friday, March 28, 2003

1) You see an internal problem.
2) You feel you have a solution.
3) You have presented the stakeholders with the right solution (right?)
4) They have declined to implement your solution.

So, what's the problem?

First, they have the right to decline to do what you suggest, even if it is the right thing.

5) Are you sure you are clear on why there is resistance to your solution? Perhaps there are business reasons for their resistance?

Clearly, what you are doing now isn't working (for you, at least). Why are you still doing it?

Your choices are:

6) Quit
7) Change tactics and try again.

If you think you can change the environment without the involvement and support of the people there, even if they technically have no say in the matter, well....

Friday, March 28, 2003


if I understood you correctly, I can see at least 2 reasons why you're getting blocked:
- you are a recent hire and it's too early for you to speak up
- you were hired for maintenance not development. They are 2 different things.

What I would try in such an environment is fix small problems one by one, as maintenance occurs. But objectively that may not mean migration to J2EE.

I guess from here it's take it or leave it.


Friday, March 28, 2003

It's hard for a company to change when they are making a "LOT" of money, as you put it.

Personally, I would be very happy with the situation.  Let the change come in small increments.

big bob
Friday, March 28, 2003

Originally you described the problem as resistance to your cutting maintenance/development costs by porting applications to J2EE. However, your later reply states the real problem is a help desk overwhelmed by configuration problems.

You are the new guy on the block and your solution to a configuration problem is to start over? I'd view you as a threat too :)

I suspect your boss expected a case by case justification for replacing each app., showing how it noticeably reduces BOTH the maintenance and the help desk costs. I get the impression your arguments for using J2EE have focused on making you more effective/efficient (a long term issue), not solving the current crisis.

I suggest you think in terms of initially refactoring some of the more troublesome applications to use common libraries/tools/config etc. Once you make the help desks life more bearable (and earn some trust) people will probably be much more receptive to your suggesting a J2EE based pilot for apps where you plan major new development.

Eric Moore
Friday, March 28, 2003

I will have to agree with Eric.

As Joel on this very web site has said in an article, determine what business function an application accomplishes.

Then determine what is working and what is broken.  Then do a cost analysis of fixing it using the old technology versus starting from scratch.

Many times in my career, the answer has been fix it with the old technology.  Just because it is old does not mean it is bad or not worth learning.

This gives you the opportunity to learn something.  That strengthens your skills as a developer.  I know 42 programming languages and I have been at it for over 20 years.  It has become easier to learn new ones as time has gone by.

It is obvious to me that you know J2EE real well.  Therefore, because it is new and because you know it so well, you want to work in that environment. 

Well, I have news for you.  Rewriting something may solve some problems, but it will always introduce other newer problems.

Also, your help desk will need to be trained in another newer technology.  This will drive the cost of your help desk up, not down, in the short term.

I wish you luck.  Take the transition slowly and you will be successful.

Bryan Shaw
Friday, March 28, 2003


Your tactics are whack.

Give up migrating everything to J2EE.  It isn't going to happen. 

You need to first solve the configuration problems.  If you manage this your in a much better position.

First of all focus on the most non-compliant or problematic applications.  For example, the powerbuilder stuff.  Migrate one of these.

In a VB/Access (ie Microsoft shop) your probably going to find .Net to be an easier migration path.  You'll probably find it a lot easier to sell to the current techies if their microsoft types.

Ged Byrne
Friday, March 28, 2003


"People hate change...
and that's because people hate change....
I want to be sure that you get my point.
People *really* hate change.
They *really, really* do."

This is a quote from a quote from the immortal book _Peopleware_.  The chapter it refers to is, unsuprisingly, about "making change possible."

You seem to be in the middle of it....

The book looks at change in this way:

1. Old status quo
    >> (Foreign element)
2. Chaos
    >> (Transforming idea)
3. Practice and integration
4. New status quo

I'm going to generalize, but I'd say that you entered the old status quo as the foreign element, that's introduced chaos with a transforming idea, who needs to get others to practice and integrate with your new setup, thus establishing (in time) a new status quo.

I most sincerely wish you good luck.

Chi Lambda
Friday, March 28, 2003

You're getting blocked because your proposal is dumb. J2EE is no panacea and brings its own awkwardness.

The original developers have working, profitable and probably very good applications. Why on earth should they switch to J2EE?

Friday, March 28, 2003

RP, have you read this yet?:

Were I in your situation, I'd want to do exactly what you want to do.  However, it's not quite what they hired you for, and as others have pointed out, all you'll do is replace the old defective code with new code and new defects.  It's always more fun to write new code than to correct someone else's old code, but then if things were fun all the time, they wouldn't call it work and pay you for it.

Consider the company's point of view:  They'll have to live with the current defective software the whole time you're busy rewriting, and only then will they get to see whether what you've done was worth paying you for (weeks?  months?) with no visible results.  As a programmer, I'd love to have that carte blanche, but if I were a businessman, I wouldn't pay for it.

If you just can't stand the thought of maintaining the apps they hired you to maintain, I suppose a possibility would be to pick the smallest, easiest app to rewrite, rewrite it quickly but carefully, and give a demo to the head honchos.  If you can show them clearly the benefits of your rewrite, they might go for it.  But keep in mind that the cleanliness and elegance of the behind-the-scenes code won't mean a thing to them; the UI and code defect issues are all that's important.

Good luck in whatever you decide to do...

Friday, March 28, 2003

Just to keep some things clear on J2EE and the internal applications:
1- The company payed for my J2EE training. My boss actually supports my idea, of rewriting everything in Java. Dump the old code and create it all again (I know this goes against Joel's teachings)

2- Our company's business evolves around a Sybase database. Actually two databases, an IQ and an ASE. Sybase has developed a great deal of Java software and I think this is more than enough of a reason to go forward with the Java thing.

3- The reason that the help-desk is always putting out some fire is that the applications are extremely faulty. We are talking about standalone applications that run on some machines and in other machines, without any explanations, don't run. When this happens, the users call the help-desk. With 80/100 users and 2 guys manning the help-desk, it's hell on earth.

Addendum - This company isnt based in the US. It has the monopoly of an extremelly wealthy source of income with the support of the government, although it's not government run (and this is a democratic country :] ). Sorry, but I can't get into more detail, that could get me into trouble.

Friday, March 28, 2003

Two problems with rewriting everything from scratch:

1) The one that Joel mentioned. Takes lot of time, new bugs, everything.

2) and the most important: when the new app will break, YOU are the one who will take the heat. You'll have lots of users saying "the old one was better". Specially since you are making such a fuss over it, the ones who opposed you are going to watch your every step.

And I do understand the reaction of your bosses: if the company depends on that software, you prefer to have something that _does_ work than to risk your whole operation - why? - so helpdesk will work less. Common.

The path that I would chose is of incremental change, if that is at all possible. If you can patch an existing application, do it. If not, you can refactor it and move it to a new language - you seem to like J2EE. If not, you can refactor parts of it and move them to the new language - the best would actually be if you could modify the apps silently, so that the users never notice. They don't like to use the browser? Me neither. Do a front app that they run on their computer that looks exactly the same as the old one.

Rewriting everything has many more costs than just getting new bugs, among them being that the users would need to migrate to the new things. Do that as painless as possible, make them not notice that, and they won't care.

You say that you don't do anything but surfing the web. That's nice, but if you are so frustrated, why don't you start refactoring one of the apps, moving it to J2EE or whatever you would choose, and then install it on their machines, incrementally. Make it compatible with the old one, and every time a user has a problem with the old one, have helpdesk install them the new one. Yes, all this backwards compatibility will be more work, but I think it is important to understand that there are many other factors in a program then just the beauty of the code...


Friday, March 28, 2003

Your company just sent you on J2EE training.  So without any experience of completing a Java project you propose to replace every app in use.  I cannot imagine when the path choosen by you and your manager could be the right one.  Your company is fortunate that others are paying attention and blocking you.

You have VB and Access.  You have ODBC.  If database connections are your problem you should be on a course or ODBC, not Java.  If your programs are not using ODBC (or ADO or other standard) then thats where the rewriting begins.

Unless you know exactly whats going wrong now, how do you know that exactly the same issue wont occur with the new Java app?

Whatever is wrong with your existing applications, it can be fixed and with a lot less effort than rewriting from scratch.

Ged Byrne
Friday, March 28, 2003

This sort of reminds me of a previous employer that back when C++ was getting popular (early 90's?) sent one of my team to a C++ course as a reward for doing a good job. Our large application was written in C.

When he returned from class he wrote the next enhancement in C++ - for our C application.  Management allowed this and, as a result, our project became a badly written C++ app instead of a decently written C one.

Just because you *can* do something doesn't mean that you *should* do it.

Friday, March 28, 2003

So to sum up your situation from the perspective of your cow-orkers, RP:

- You haven't actually done anything worth mentioning.
- You want to change *everything*, right now.

That can be done, but you'll need to inspire trust that life will be nothing but puppies and bunnies if you get to proceed.  One method for accomplishing this is:  do something worth mentioning.

Step 1:  Pick one small and innocuous app -- limited in scope to one department, and make sure that department has a user in it with a lot of domain knowledge.  Take that user out to lunch.  Repeatedly.  My experience has been that most end-users are absolutely thrilled to get to talk to an actual programmer, and can be a wonderful source of ideas for program improvements.  Odds are the existing app doesn't meet at least one major requirement, and they're maintaining an Excel spreadsheet with the info they actually need.

Step 2:  Rewrite said app in your spare time, referring as often as necessary to your end-user ally.

Step 3:  Send your boss a report (in printable form) which clearly shows the benefits of the rewrite.  Better yet, have your end-user ally send it -- if you've done even a halfway decent job, they'll be thrilled to.

Naturally, you'll need to do your current job while this is going on, but since you're just surfing the web and being pissed, that shouldn't be too hard.  (=

Sam Gray
Friday, March 28, 2003

Yes, you are being unreasonable.

As someone who has been stuck writing J2EE software from time to time, I can tell you now, you are trying to use the WRONG tool for the task you described. Ged has the most reasonable advice.

Friday, March 28, 2003

Just to clarify my ODBC point.

Abstracting the datalayer was cracked some time ago.  You shouldn't be basing the choice of front end on the database being used, because the database is always accessed through an abstraction layer like ODBC or JDBC.

Ged Byrne
Friday, March 28, 2003

I would take a slightly different path than Sam.  I think you need to spend some time doing some basic problem solving (instead of surfing the web) before you re-write any of the applications.

First, does the help desk keep a log?  Is there any data that you can pull together and do a simple Pareto analysis? Instead of taking on a small app, you might want to take on the app that causes the most number of problems. Then do some root cause analysis.

Once you have defined the problem, develop an implementation-independent model of the application and determine the steps necessary to refactor the app in its existing platform.  If you're stuck on the J2EE idea (against  the advice here), determine the steps necessary to re-write it as a J2EE.  Weigh the pro / cons of each.

Present these to your boss and co-workers.  Be prepared to have the J2EE version shot down by your co-workers, even if it's a better solution.  That's okay - businesses aren't meritocracies.  But, if you refactor it, you will have reduced the help desk's work load (hero) and shown a willingness to listen to you co-workers.

First, this will demonstrate that you add value to the company. You don't just write code - you write code that solves problems and saves money.  Second, and perhaps more importantly, it will bridge the gap between you and your co-workers.  Showing them that you are willing to listen to them will make them much more likely to listen to you next time.

Then, after establishing a repoire with your co-workers, do what Sam suggested.

Lastly, I have seen many instances of Access applications performing erratically on some PC's and fine on others - all running the same OS.  Typically it's a "DLL hell" issue. For example, one Access app that I know of stopped working properly after users installed MS Project.  So there are some maintenance issues that may warrant a move to a single database platform (Sybase in this case).  But do your homework before trying to move all your apps from known, established platforms to one that you just learned.

Friday, March 28, 2003


I understand your dissatisfaction. But you've gotten some really good advice in this thread.

No matter that you believe that your J2EE emphasis has been management endorsed, the problem is that when it comes down to reimplementation of existing applications, you'll consistently get no support from anyone. You've proven as much.

I suspect that instead of conservative wisdom guiding your peer's opinion of your initiatives as everyone here is optimistically indicating -  I would bet that your co-workers are, indeed, covering their butts and scared to death that something that they don't know will "pollute" the local environment. Unlike others here, I'm not too accommodating to entrenched players. They usually get stupid after awhile, and they have seniority, and that's life.

And even if you could pull it off and you're capable, there are several deal killers that I would consider if you were pitching this to me:

- You're new to the company.
- You're unproven on a large scale project to that company.
- You've not done a J2EE implementation before (have you?)
- You probably haven't considered the phasing in and transition plan needed to migrate everyone from old stuff to your stuff.

Personally, I think you're going to have to manage your own tasks; start making friends with users; and find things to do that won't represent collossal threats to the current order of things. And slip J2EE into new projects as possible w/o making a big deal about it.

You're probably scaring the crap out of these old geezers by emphasizing "CHANGE". Everyone starting a new job needs to approach changes to the organization incrementally.

Have you considered sitting down with a manager and replaying this scenario? If you do, keep the focus on benefits to them at all costs, otherwise you will come off as a whiner.

If it helps, consider that if the bosses dictated J2EE, your sandbagging coworkers would probably ask for transfers, quit or go into hiding. You just don't have any power to unilaterally demand a sea change.

Be incremental, my friend...

Bored Bystander
Friday, March 28, 2003

> They're written in lots of different languages, so I decided to migrate them to a J2EE environment.

Who the hell made this decision?  You?  You are in NO position to make ANY such decision.

> Instead of developing a full-blown J2EE application, I had to keep myself happy with a couple of servlets that don't even get used regularly.

Porting an existing suite of internal apps just for ease of maintenance is a RETARDED reason to migrate.  You are an idiot, the older staff have a clue, you do not.

Only an ASS selects the work to do based on what languages he wants to code in.  Have you considered what the business NEEDS? 

You should quit.  You are a liability to any employer, if not strictly managed.

Friday, March 28, 2003

Doubtless he thanks you, Bella, for such constructive criticism.

Saturday, March 29, 2003

Had a tough night flipping burgers, bella?

Saturday, March 29, 2003

Wow Bella, and I thought I was being tough on the guy.

Still, can't say I completely disagree.

Be fair, though.  How many of us have been in the same position.  New kid on the block wanting to rewrite the world.

Ged Byrne
Saturday, March 29, 2003

flipping burgers?  Go read my posting history.  You'll see quite the opposite. 

Saturday, March 29, 2003


did you read this?

Prakash S
Saturday, March 29, 2003

Bella, exactly what does it buy you to treat this guy like a vain stupid a$$hole who deserves to get fired? At least he ASKED.  The biggest a$$wipes I've run into never ask anyone anything.

And you're reiterating the exact points that have already been made several times throughout the thread, but in a much ruder manner.

I do make a point to read your stuff and generally you're right on the mark.

And yeahyeahyeah free speech and all that crap and you're entitled to your say blablabla, but you troll with a major chip on your shoulder. Someone with self confidence arising from the industry experience you lay claim to would have no need to flame people asking valid questions. There's a lot of cognitive dissonance arising from anyone that claims to be a seasoned retired expert who acts the schoolground bully part.

Bored Bystander
Saturday, March 29, 2003

I agree with you.  For some reason, I have a need to post in a hostile manner.  I do not know why.  Pent up resentment towards IT inefficiencies?  Or maybe it's just more fun that way.    Or maybe I'm just trying to be noticed?  Thank you for validating my posts.  I do feeel I post accurate and insightful information, albeit in a rude dsigusting tone and manner.

Sunday, March 30, 2003

Like you, RP, I walked into my organization and saw that we were using tools poorly or could use new tools to increase efficiency.  However I'm new to the company and a recent college grad.  So were I to confront my co-workers and suggest that we reprogram certain apps, or make use of different tools I would expect to face a lot of friction, despite my manager's opinion.

I have slowly been working my suggestions into the culture.  We're slowly starting to use a bug db, we're slowly refactoring our code and leveraging common code.  And at every step I'm writing documentation, business cases, and functional specs.

I was asked early on to develop an Access db and I tossed it together quickly.  Once its value was seen we added layer upon layer to it and now it is quite unmanageable and maintenance is difficult and tiresome.  But rather than jump in and start recoding I'm taking an analytical approach, I suggest you do the same.

I am rewriting the functional spec currently, subsequently I will draft a gap analysis to see where the current design falls short of the actual needs.  After that I'll draft some specifications and a technical spec, invite commentary and begin a redesign - all the white maintaining the old system.  In this way I hope to build internal support and offer both technical and business reasons for the time and effort spent on reprogramming.  Certainly I could rip out a new version in a few days where this will take a week or two, but the end result will be a better designed application that better suits our needs and has the support necessary to make it happen.

Best of luck changing your company - but recognize that change doesn't happen because you proclaim it, it happens slowly and with effort.  Put forth the effort, talk to the other programmers, discuss refactoring current designs, consider DB migration, make plans, write specs and discuss it with all parties.  I think you'll find that you are taken more seriously and will receive more support than you expect.

Sunday, March 30, 2003

My own bit of history. Every time I've switched jobs (about 3 times in 8-9 years) I wanted to rewrite everything. And I mean everything. I managed to do it once, and boy, never will do something that stupid again.
In my current job I've replaced about 50% of the internal tools, incorporated a lot of good practices (CVS, for example) and helped to let the fear of change fade. But it took a year, and I think I'm being fast :-)

Leonardo Herrera
Tuesday, April 1, 2003


Just to add one more voice to the crowd:

Take a deep breath, close your eyes, relax.
Let's look at it from "the other side":

1> New hire (I don't want to be rude but I guess we can deduct from the story so far) as green as the very first sprout of spring, walks in.
2> One low level manager, drank the Java Cool-Aid for managers, sends our friend on a J2EE course. Still no real harm done here. Knowledge is good.
3> Junior comes back (Add to resume: Mission Critical Enterprise Application Architecture/Design/Development: whole week of J2EE classes), fully enarmored, and declares that all current running systems should be scrapped, and a big nuclear bang rewrite in the shiny new silver bulled technology should start right now!
4> When the real developers do not stand in awe as if the lights of heaven had just shone trough, junior subscribes this to "stupidity" and sees all actions against his big plan as political lowdown foul play to block the path of the one truth.
5> Junior slumps down into his monks cell, bitter. If they do not buy this, sod it. It's my way or the highway.

Doesn't look so good from this side, does it?

Just me (Sir to you)
Friday, April 4, 2003

I just wanted to close this thread.

Your answers have been way beyond awesome. Although I am not that green (3rd year as a software developer), you did make me see the light.
Yes, I am taking it way more easily now. I am not even angry anymore. I know for a fact that things will end up being my way, that was written by management way upstairs. All I have to do is relax, and NOT TAKE IT PERSONALLY.

So, right now I found that not being pissed of makes my days go by more easily, I don't have a stomach burn after lunch, and I am getting along better with everybody else.

Thanks guys!

Wednesday, April 9, 2003

*  Recent Topics

*  Fog Creek Home