1

I started working in a project around 3 months ago and since I joined I saw so many mistakes in the whole design - the architecture is completely dysfunctional and badly implemented and a lot of used concepts like Inversion of Control are implemented in a way which completely goes against any proper conventions. People have different opinions, knowledge, experience and it's completely fine to solve a problem using different approaches the problem is when things are implemented in a very wrong way. Given that there are so many issues with the current design I will describe one as an example.

We have a good few components and each is defined by a set of different projects (we are using C#) like so:

  • Company.Product.Repositories
  • Company.Product.Repositories.Contracts

  • Company.Product.Repositories.IoC (RepositoriesIoCManager)

  • Company.Product.Services

  • Company.Product.Services.Contracts
  • Company.Product.Services.IoC (ServicesIoCManager)

In the IoC project we have a couple of windsor castle installers to configure the dependencies for that specific component, so given the example above we would have two installers one per each component

Now let's say that the Services component has an indirect dependency on the Repositories - which is a typical setup - in our case the Services project has a direct reference to the Repositories project and calls a static method in the RepositoriesIoCManager type to initiate the IoC installer. This setup only works because we have a single product/region and no CI, and it would easily break in case we had different Repository implementations for the same interface, you just could not swap the different DLLs during the build/package/deploy process cause everything is statically referenced.

Among other issues, this just makes the use of IoC completely unnecessary, because we don't even have unit tests, so there's nothing to mock.

I tried to explain the guy how the concept is broken, that IoC is used among other things to allow loose coupling between components, which is the opposite we have here but every time I do so, I'm told I am not flexibly and that pattern X is just like any other pattern and I just can't find any more arguments. What would you do in this case? make a demo project and try to get people see what problems IoC solves and how it should be properly implemented or just accept that this is yet another "custom" way of implementing IoC?

UPDATE

Data Projects

|improve this question
  • 1. Using IoC containers in most cases is not necessary. IoC / DI itself is good. 2. It sounds like you are dealing with cowboy / "pragmatic" developers - there is nothing you can do. Either change job or make sure you work on a completely independent piece of work isolated from their crap. – Den Aug 12 '16 at 10:28
  • Leaving the job is actually something I am deeply thinking again, but I was abroad working for an F1 team and gave up that work to return home and I really though the job was good given the stack they were using, but believe it or not, SOLID is not even something they are aware off. I don't usually give up but I don't know what to do to help them change a few things here. This project started just a couple of months are suffered two major refactoring already :( – MeTitus Aug 12 '16 at 10:35
  • Sounds more like cargo cult programming to me. IOC/DI is about simplifying change. N.B. just because there are no unit tests or mocks, that doesn't make DI/IOC redundant but there has to be a proven case such as pending RDBMS vendor change or such like. I've been in jobs where you're beating your head against a brick wall trying to get people to see the light and it isn't fun. If you're getting paid silly money then stay, otherwise head for the door. – Robbie Dee Aug 12 '16 at 10:51
  • ...so many mistakes...architecture is completely dysfunctional...badly implemented...implemented in a way which completely goes against any proper conventions... I've been there so many times, ... Welcome to the club! You face two problems: (A) convincing the proud authors of the code (if they're still around) that there are better ways, and (B) convincing management that there's a business case for reducing the technical debt. (A) can be done if you've got the right people skills. (B) can be difficult unless there really is a business case. – Solomon Slow Aug 12 '16 at 10:53
  • @RobbieDee I completely agree with you, DI is not redundant just because there aren't any unit tests, the problem is that since they link the projects statically, the other obvious reason for them to use DI would be because of the tests, since component isolation is not one of them, but they don't even have unit tests. I could leave straight, but I left a job in a F1 team just because I wanted to come back home and it feels so bad to leave, but I looks like I lost battle. – MeTitus Aug 12 '16 at 11:05
3

The code works though right?

Let me answer this question in terms of software design with legacy problems, as I think your 'how do I convince my boss that...' Is probably a bit off topic.

First of all limit your concerns to the bit of code that you are currently writing.

Make sure you add unit tests for it.

Then you may find that due to static methods/linking etc you have a problem which requires refactoring other components.

Do the minimum code changes required to make your code/tests work without forcing breaking changes on other components.

You then have concrete reasons why you need those changes, you avoid creating problems with 'legacy' code and you can gradually introduce new paradigms of programming to the code base.

|improve this answer
  • That might be a good thing to do alright. It will be hard to introduce unit testing to the code without introducing some breaking changes but I can try to go down that path and see if I can get something out of it although to be fair, I was told that the logic using their own understanding of what IoC and UoW is, it's here to stay. – MeTitus Aug 12 '16 at 12:59
  • And yes the code works, but believe me, the thing is all tied together, static dependencies between all the projects and that's not even the worst. I can continue, ignore and just keep doing it for a little while more, and although there's no magic solution to make pride people accept their knowledge about things is wrong and is making everyone's life harder, the reason I asked this question is because I honestly want to hear what people have done in similar situations. I could all of a sudden just leave but at the end of the day, we can't run away from problems all the time. – MeTitus Aug 12 '16 at 13:05
  • If it works its fine. You have to let people do their own thing. The only concern you should have is that they let you do your own thing too – Ewan Aug 12 '16 at 13:53
  • Well I guess I was deceived and this was a lost battle since the beginning. There's always a list of things I ask when I am interview with a company, I guess I just need to ask a few more and also ask to look briefly at their code base. – MeTitus Aug 12 '16 at 13:56
  • @Marco It is impossible to vet a company completely. Take it as a lesson learned and move on... – Robbie Dee Aug 12 '16 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.