Q:

How to improve enterprise level application that consists of only static methods

I am new in a enterprise level application project and discovered that 99% of everything I've seen in code is static methods, static properties.
The application at hand is a distributed app consisting of about a handful of WCF services that communicate through a business layer with a data access layer. The data access component is a singleton. 
There are transactions and MSMQ queues and multiple parties calling the WCF Services to notify the DB of changes, updates made in a seperate system and so forth.
First time running a little test project I got a thread related exception using EntLib5 Logging, telling me that some code was called from an unsynchronized code block.
I am curious to know how one should go about and improve an almost-all-static design.

Are there advantages to the current approach? 
What are the disadvantages?
Where would you start (besides starting over) and improve all this
  mess?

Thanks for your opinions!

A:

When the application only consists of static methods it is clearly not object oriented (however, this doesn't mean that you should never have any static methods). Further more you will probably have little to no unit tests (since testing static things is almost impossible). The only advantage I can think of is that walking the call graph in the application is easy, because it is all static, but that's what where it stops.
I always favor a design around dependency injection, which enables unit testing, and enables you to plug in new functionality and cross cutting concerns (such as logging and security) more easily.
I still wouldn't exist to start all over again, because that is way too expensive (especially in an enterprise application) and it would be very hard to realistically estimate the time it would take (what would freak managers out) and you'll be wasting your bosses money.
No, instead, learn about object oriented design, unit testing, TDD, the SOLID principles, clean code, and dependency injection. After that, try improving the application in small chunks at the time. Try writing new code according to these principles and before changing old code (both for bug fixing and changing functionality) try to write automated tests for that part of the system. This way you can improve the code with more certainty.
It takes a lot of time to learn, and working this way takes a lot of time too. However, as you said yourself, you are in a mess, and not going out of this mess, means that at one point in time it will get impossible to change anything in the code base. The result will be that in the future you can make changes with more certainty and the system will get more maintainable and more resistant to change.
Good luck.

