Managing a difficult manager

Question

I have a situation here at work. We are redeveloping our basic architecture across the entire company.

Currently we have the following hierarchy;

SQL Database <= Stored Procs not allowed.

nHibernate

Classes to convert nHibernate into our own objects

Web Service <= for all external and [internal] calls.

Class to take objects from Web Service and back into our own objects

and then…

Normal nTier application architecture such as Data Transformation Layer, Business layer etc.

Within the database, when we are writing a hierarchy of objects to the database, say for example;

Order

Person

Details Address Product
Other

We need to serialise the object and save it, in its entirety, to an image field in a table. No attempt has been made to store the objects in their own tables so that we can do useful stuff like report on it.

This is an architecture that was implemented [way] before I started and as you can probably appreciate, is a complete nightmare not to mention slow as a wet weekend.

We’re not even allowed to have stored procs within SQL server because in my boss’s last job they had a hundred or so and he had a problem identifying them all so therefore all stored procs are the devil.

Now the same person that developed the above architecture has developed the new one. It came as no surprise that he’s essentially used the same framework only now it’s using DotNet 3.5 with interfaces and generics.

We still have to go through web services, still need to serialise (everything), still not allowed to use stored procs etc. In fact, we’re only barely able to bang two rocks together here.

He says to us that the framework is open for discussion but when you discuss it, unless you approve of his design, you are told flatly “No”. He simply won’t listen to any other suggestions. Even when you show him demo applications of his proposed architecture v’s yours and he can see the speed difference, he still won’t take that on board.

So I guess my question is, and I know others have experienced the same things out there, how do I get through to someone like this? How do you convince someone to ditch Web Services for internal calls and applications? How do you demonstrate, and make it stick, that stored procs are a better way to go than ad-hoc sql statements?

This is killing me. I don’t want to repeat the mistakes of the past and I certainly don’t want to write code that I know is going to be slow and cumbersome.

Help!

Answer 1

Sometimes you just can't. Oftentimes people need to realise their mistakes on their own, without you forcing it on them (not saying you're doing this).

It's up to you to decide how much you are willing to put on the line to get your point across. Always be polite and friendly, and try and show as much evidence as possible for your views, but if they fails ...

Do try and look at things from their point of view though (money saving, time, initial cost, potential sales, etc, etc). Can't hurt. But if reasonable discussion isn't possible, I'd reconsider my options.

Answer 2

Quit.

You won't get through to him. Your best bet is to try and find a different place to work. The role of the boss in a software team is to create the right environment and team dynamic, not to dictate arbitrary design principals. Good software people realize this. Those that don't are, by definition, not good.

Answer 3

A couple of strategies:

1. Make a proposal, and compare the two designs. Make a list of pros and cons for each. Highlight what your design can do easily. Make sure to include the cost of switching designs and getting people up to speed with the new design. Be honest.
2. Make a prototype. Show what the prototype can do, and how quickly and easilly it can do it. Do this in conjunction with the first strategy.
3. Be subversive. Go along with the design, and gently nudge it into a proper direction over time.
4. Find allies, especially other leads/managers if possible. Get people who agree with your worldview, and work with them on any of the above.
5. Make sure you're looking at value from the customer point of view! If there's no visible difference, then the only valid point of comparison is cost of development and maintenance between the two designs. Nobody cares about the internals of your app - they only care about how many neat things it does, and how much it costs to build.
6. Work with the manager to get on his good side, and get some trust built up. Once your opinion is trusted, you may have a better chance of making design "suggestions." Establishing an adversarial relationship will not help you.
7. Figure out why your manager thinks this design is better. Figure out what is motivating him, and what he is evaluated on. Use that knowledge to your advantage.
8. As you're building, make sure that you abstract the 'badness' out sufficiently that it can be removed later. If the design is bad, then this should become apparent, and if the cost to change the design is minimized, there's a better chance of getting to do this.

If you can't make a good case as to why it makes business sense (customer value/cost of implementation) to favor your design, then you should ask why you think your design is better. It may not be. If there is a valid business case to be made, and nobody will listen, and none of the above strategies work, a time may come to consider other options.

Answer 4

Organizational change is hard, especially in the face of certain... 'personalities'.

Are these decisions down to a single manager? Or do these ideas have buy in from other people at the company? How easy is it to get to them?

Have a read through James Shore's "Change Diary". The introductory quote is instructive: "You can Change Your Organization or Change Your Organization." -- Martin Fowler. It's more about introducing Agile processes to a workplace, but some of the approaches he approaches the task may well be relevant.

Try to avoid "X approach is better", and "X is wrong" type conversations though, since they can be interpreted as personal attacks, or even ignorance (eg your manager seems to have a reason for not liking stored procs -- even if it doesn't seem correct to you).

And given that you have many alternative designs and approaches, each of which can make the product and development process better, look for situations where they can demonstrate their worth and highlight the value of those improvements (eg Improved reliability, performance, etc). Always be constructive and cooperative.

Answer 5

Gee - this guy was hard work at times....most of the suggestions won't work unfortunately. He has a hard-coded interface closed for modification and not open for extension. ;-)