I am a Java Programmer and I am relatively new to Java(1 Year). I am working for a small startup company.My problem is a bit strange and I am facing it a bit difficult to deal with and explain also.My director in the company usually assigns some programming tasks on the product we are developing. He is not from Java background, but from databases background. Usually he cares about application configuration and pluggable architecture which is very much desirable.What according to him is pluggable is obtaining object instances through Java Reflection. Always he insists us to write a class that reads an xml file where it is written which class has to be instantiated and do actual work from that object instantiated using reflection. I tried to explain about DI frameworks such as Spring and Java EE CDI, but of no use.And he thinks that whenever an xml file structure is changed, its parsing code or writing code need not be changed. We, the programmers, prefer using JAXB for marshalling and unmarshalling the xmls as it is intuitive.Very frequently he complains that the code is slow, or the programmers are incapable of providing an architecture that allows absolutely no change in Java code but all changes in xml configuration/data are consumed by the application. And every single possible decision we make are with his consent regarding finalising the xmls structure. Accordingly we code and develop things. But after some period he finds something else is fascinating and asks us to change the whole structure of the xml. Change in requirements is not a problem, but he thinks Java code need never be changed and keeps blaming that the programmers are incapable of writing code in such a way.Is it really possible? How do we convince him or explain?
How do I deal with the following technical issue?
java;project management;xml
1) Where your manager is rightYour manager wants a flexible architecture. To accomplish this, you have to design our code, that it is easily composed of pluggable components. What according to him is pluggable is obtaining object instances through Java ReflectionThat is a way to organize object creation and is how DI-frameworks do their job.Typically you mark dependencies of an object using @Inject annotation. I do not see any sense in doing this by hand, when you have frameworks to do the job reliably.he insists us to write a class that reads an xml file where it is written which class has to be instantiated and do actual reading from that object instantiated using reflection.Sounds to me, that he wants to develop his own version of Spring with all the legacy pains of using XML for (container) configration2) Where your manager is (terribly) wrongAnd he thinks that whenever an xml file structure is changed, its parsing code or writing code need not be changed. This sounds like a weird version of the open/closed principle, where a class should be open for extension, but closed for modification. A better design would be to refactor the parsing behaviour out to an interface. Then you are able to keep your overall logic dealing with the result and handle different types of Parsers with different objects.If you want to deal with different versions of your XML at the same time, you could design different parsers for each version. But if you only want to deal with a current version of your XML, it would make sense, to only update the code of the one parser, you have. If you never refactor your code and only pile classes you end with a mess.We, the programmers, prefer using JAXB for marshalling and unmarshalling the xmls as it is intuitive.Which is - in short - perfectly fine.Very frequently he complains that the code is slow, or the programmers are incapable of providing an architectureAs far as I see, the only one providing a messy architecture is your boss. Sorry, bro!@ddyer gave you a hint, on how to convince your boss: Benchmarks - hard numbers / facts. Rewrite a part of the code and show the differences.But after some period he finds something else is fascinating and asks us to change the whole structure of the xml. That's how management (oftentimes) is.tl;drWhat to do?In case you want to convice your boss:If your time allows it, rewrite the application (partially) or at least do a fast prototype which has the core elements of the application, benchmark it, show the numbers to your boss. Perhaps you could do a comparing code review of how the old codebase looks like and the new one. And speak with him about the differences.But honestly: If you have the possibility - leave the company You are doing yourself a big favour.This sounds like a very bad environment for productive work. You are the programmer(s) and you are in charge for the codebase not your manager; or if he feels so - and that's what came to my mind reading your story, he should do your job (alone). As a professional software developer you should stand up against your boss. But it depends on the possibilites to get a new job. Perhaps you are in a dilemma of quitting, but having no alternative.