Persuade boss dump terrible architecture

Question

I'm close to having a nervous breakdown, so please-please help me out.

A bit of background: I'm in Russia, working for a financial company and we're developing an in-house application for our back-office, executives, you name it.

The application contains several major areas, and I personally worked on reporting: the whole infrastructure with visual designers and such. All neat & beautiful. I did my best to make my part sing and dance, and I tried to use good development practices and tools (Spring.NET, NHibernate, a few other niceties).

And now here's the original architecture and process looks like (I'll do my best to express how horrific these two are). We're using LLBLGen Pro, which is not-so-bad tool by itself, but listen.

A usually simple process of adding a single domain class requires you to:

• Create database tables (10 min. for simple ones)
• Launch LLBLGen editor, open up Project file (couple of minutes)
• Force LLBLGen to refresh DB schema (its HUGE, so another 10 minutes)
• Add required tables, regenerate code (10 more minutes or so)
• Rebuild DAL assembly (a couple of minutes, what end up with is 11+ meg DAL.dll)
• Create a so-called BL interface which effectively duplicates all the properties of a generated DAL entity
• Create an interface for the collection of BL objects
• Implement BL interface. This is horrendous, I'm very sorry guys, but I want you to feel the scale of the disaster. And yes, this is all hand-written code (except for properties, which are generated by ReSharper). And yes, all imaginable logic goes inside the domain object. This all in all takes up to 2 hours.3
• Add a row to the database with the name of the class

• Modify a handful of hand-written "converter" classes, which basically map from one enum to another:

  public static EntityType Convert(Interfaces.EntityType entityType)
  {
      switch (entityType)
      {
          case Interfaces.EntityType.Asset:
              return EntityType.AssetEntity;
  

(and this goes on for 700 lines; there are 5 similar files). No compile-time warnings when something's missing, nothing. You get slapped with a runtime exception in case you forgot something.

• Implement collection interface, embedding all query logic inside.
• Add a methods to a Remoting Server interface, which is 5000 lines already an ReSharper is choking heavily.
• Implement the said methods

And now you're ready do the most basic stuff.

Implications are as follows:

• Huge amounts of code which is a nightmare to support
• Woeful architecture (for instance, I cannot create an instance of a domain class on the client-side: I have to go all the way to server asking it to retrieve from the DB an object with Guid.NewGuid() as an ID)
• It's downright impossible to test anything.
• The whole application works terribly slow.

I've already tried talking to my boss about this situation, but he wouldn't listen. The only thing he responds with is that "So what? I don't care writing that much code. And it works!"

How can I persuade him to think once more? My part of the project seems not to impress him neither with how succinict it is, nor with my speed of development.

Answer 1

resign. if you don't like your job and there is nothing you can do to change it then change your job.

Answer 2

Anton,

I've been a professional financial software developer for over 20 years and whenever I come across a situation like this I find the best approach and usually the only one that works with a "resistant to change" boss is to actually develop the alternative solution yourself in your own time and then present it to him.

Some people are visionaries, others need to see it working to understand how much better it is. Get a tester down the pub and start discussing what the bottlenecks are with the exisitng system and use these as performance indicators for your new system to measure against.

Answer 3

I was once in a similar situation, also working on back-office systems. Getting a simple change for our server (designed long before I came on board) out of the door could take weeks, but it was fast and did "work". The thing that got the bank to allow us to redesign was that the clients of our server, other back-office apps, wanted changes made faster than the architecture could support them. Due to pressure from those clients on management, we got the go-ahead to do a very succesful re-design and re-implementation from scratch.

So, bottom-line is you need pressure for change from somewhere other than just the developers. If your system is as clunky as you say, there must be unhappy users out there - get them to complain more loudly!

Answer 4

You can save some time on the LLBLGen portions of the process by using the command line tools to refresh the schema and generate the code. Check the LLBLGen support forums for more info.

Answer 5

I was in a similar situation on my first job. The architecture looked good on paper but in reality is was a nightmare to maintain and most importantly performance was terrible.

But it didn't matter how many times I told the architect in charge about these problems: he didn't want to listen.

This was one of the most important reasons I quit that job. Afterwards I heard the entire project was put into the freezer (we all know what that means) 3 months after I left.

Just go and find a better job and leave them alone with their problems.

Answer 6

Make him read this post and our answers :)

Answer 7

Its never going to fly for all the reasons you have eloquantly explained, so you have a couple of choices.

1) Leave and watch it collapse from afar

2) Stay and knuckle down - live with it, take the pay, and await the collapse

3) Email someone super senior indicating that project X, should be renamed project Titanic and hope someone is listening. Normally the person who's money/budget your spending is a good choice.

4) Show your boss this SO post

Option 3 is the most courageous, but also the most dangerous, it seems unlikely that this project will change (none of the ones that I've been on like this ever have). So whistleblowing and then staying/moving on is your only options.

Answer 8

Instead of re-writing the architecture, another possibility would be to write your own code generating tools to do all the drudge work. Check out the System.CodeDom namespace rather than attempting to write your own code parser.

The advantage of that is your boss doesn't even need to know, let alone approve what you're doing. :-)