Is it normal to run all you code through a "Software Architect"

Question

I am a software developer and a few months ago I started working on a new project. However, unlike all the other projects I have worked on, in my current team there is a "Software Architect" who gets to define every piece of the architecture of the application we build + is constantly messing even in some very low-level implementation details.

I have worked in this same company for a while (almost 6 years) and in all the projects I have worked on I have had creative freedom - i.e. I get to come up with both the design and the implementation of the tasks I take and only afterwards someone makes a review and I (eventually) apply some (minor) changes. Now, before I start implementing anything I have to first discuss my implementation plan with the architect who changes it as he wishes. I'm quite unhappy with this new situation where I'm treated like a construction worker who can't do anything without first being instructed how it should be done and I'm getting into some lengthy and not very friendly discussions with this guy (who is the tech lead for the project and more or less my boss).

Since I don't have that much experience, I was wondering - is this a normal workflow? Is it widely adopted? I feel some tension between me and this guy (basically I'm a bit sick of him telling me what to do) - how do I deal with this?

Answer 1

Let's start with the obvious workplace issues that have nothing to do with software development. You have stated he is your boss. He has every right to determine how he wants to manage design. It is not your call unless he decides it is your call. It is counterproductive to get upset about that. It is risky for your career at that particular place to get mad about him doing something that is a part of his ordinary responsibilities.

There are projects where this type of overarching design is common especially if the project is using Waterfall methodologies instead of Agile. It is common when there is a strong regulatory or legal aspect to the software or where the cost for bugs is very high such as in the Space program or for medical devices. In those worlds it is very critical that the design be done in advance and approved and that there be no deviation from the design without approval.

Whether your project falls into one of these categories is almost irrelevant though. The person in charge wants to use that technique and you have an obligation to follow his direction in this and to not resist it. It is what you are being paid for.

What you can do in this situation is do as you are asked to do. You can have professional discussions of alternative methods, but do not ever go behind his back and do things against the way he has designed the system even if you don't agree with his design. There are considerations you may not be aware of and to do so is insubordination and grounds for dismissal.

If you professionally discuss an alternative way to do things and he decides against your suggestion, then take it professionally and do not continue to argue. The decision in this project is his and he is the one who will have to pay the price if he was wrong. In no case should you argue. It is entirely possible to have cordial professional discussions of technical alternatives. This is a skill you need to have to be successful anyway, so this gives you a chance to practice. It is best to discuss alternatives at the start when things are first brought up not later after other parts of the project are depending on things being done in a certain way.

The more you support his decisions, the more likely he will listen to you when it is critical. Do not argue minor points.

You have apparently worked at this company for a long time, so work on this project and look for a project run by someone else to volunteer for. Or search out a new job if you can't deal with a perfectly reasonable management requirement. But don't ruin what reputation you have at this company by becoming known as the angry person who is not a team player. Stick it out and move to a different project. Use the opportunity to learn things about architecture that he can teach you and things like how to manage subordinates which are sometimes learned best by working for someone whose style is not your preferred one.

In your career, you will have to work with many different types of people with many different styles of management. You will work with people you don't personally like. You need to learn how to work with different styles and personality types and how to effectively present your ideas when you don't have free reign to do what you want. This is therefore an excellent opportunity for you to grow your soft skills.

Answer 2

I guess it depends on how low-level this guy is micromanaging you, but yes it isn't out of the ordinary for a lead developer to dictate exactly how a particular process should be made to work. Sometimes - granted, generally when a person is working with very junior developers - you'll see someone go as far as naming the classes and defining function signatures. There's also very often a great deal of leeway on the other side in terms of being able to dictate how you solve a particular problem, but I will say that most places have a BA or an architect who does step in and define at least some of the design (ideally by conferencing with stakeholders, which, if you're a programmer you probably don't want to do anyway, so be thankful for these people), specifications, and requirements before leaving you to come up with the rest.

Answer 3

It's could be that the project that your working on has to conform to compliance and governance. In my role as a Technical Architect, I have to review everything that the development team does. This is due to the fact that all development is done by offshore third party consultancies, we do not do in-house development, so I have a technical oversight role (we have 1 architect per LOB application). In some situations I will put together architecture documents where the UML diagrams identify the classes and method signatures as well as design patterns and software structure. In other situations I will review the code that has been implemented, compare it to our guidelines and standards, I'll also do code and performance analysis. Basically, the job I'm employed to do, in may respects, sounds like the Software Architect in your question.

Why do I work like this? The reason is is that historically, the business has been let down by it's suppliers and as we are bound by regulatory compliance, then I have to act as a gatekeeper and arbiter of what the business has to use. When a LOB application, like the one I work on has leaked £25m in one year because of incorrect calculations. That ends up having to increase FTE (Full Time Employee) headcount because of poor performance when the purpose of the application is to reduce FTE head count. Then the business tend to say "We need someone to take responsibility and watch over what we are getting", so it's my neck on the chopping block, not the developers (unless the situation your actually dealing with is a blame down culture, unlike mine which is the buck stops with me).

While I would agree that for many applications what I do and what your experiencing is not "Normal" workflow, it may be best for you to check with a Senior Stakeholder or the Architect as to why it has to be that way, it could just be that the project requires regulatory compliance, governance and oversight.

Answer 4

It can vary but if you have an architect and that is how they chose to handle the role there is not much you can do about it. And you will get the shit projects. One argument is everything the same way even if it is not the best for each individual program has maintenance value. If you argue they just seem to clamp down more. Take challenge in making their way work.

Where I get fairly frustrated is when I know I would personally test a 2 or more approaches to see what works best.

If I know performance is going to tank I will bring it up quietly once and then just let their design tank.

What is really fun is when the data base architect does not have to conform to the software architect and your business objects don't align with the database design. I have been there and you just need to let them duke it out. When software architect (that does not know database) tells a database architect how to do database design things really get fun.

Answer 5

No, your situation is a bit extreme. You have someone as an architect who's a bit anal retentive there. Code reviews are one thing, but if you can't sit down and code without having someone dictate to you before you work, that's a whole different thing. This approach can only work in a small shop, and won't scale. Can you imagine a team of 25, 30, 35 developers all having to wait their turn to see an architect before writing code? It's time for some serious decision making on your part.

Answer 6

If you have been working there as a software developer for six years, then the situation is absolutely not normal. It is entirely counter productive. I know there are a lot of people who subscribe to the theory "do as you are told". The reality is that everybody will unconsciously try to prove they are right. If you come up with your own design you will unconsciously try to prove that it works. If some anal retentive "architect" forces you to follow his instructions you will subconsciously try to prove that your are right, which means you will subconsciously want to fail. When advice is given, it should be to get people on the right path, and nothing else.

You can do two things: Go to your boss (above the "architect") and tell them that you are unhappy with the situation and why. If you worked there for six years doing a good job there is a chance that your boss agrees with you. If that doesn't work, look for a job elsewhere. There's also the rule that often you have to change jobs to get promotions and/or salary raises, so that might work out doubly well.

Answer 7

It couldn't be considered normal. If he knew exactly how the work should be done, why he couldn't do it by himself? The hard part in a development is figuring out how the application should internally work and how the code should be structured.
The only situation when manager could interfere with coding process before code review is mentoring new employee, but if you have ~6 years of experience, that is not the case.

The code review, extensive documentation of good practices and standards is one thing, but micromanaging is terrible mistake made by terrible managers. If there is a business need of very structured and rigid development process, let the manager document it.

Answer 8

Yes, some companies, maybe even major half of them, are now pushing the highly hierarchical, controlled work organization of software engineering and for them this would be normal. Yes, you probably may get fired even for showing more obviously your are not satisfied with these new winds. Also yes, I fully understand that this new experience may be extremely frustrating, and the more competence and experience you have yourself, the more frustrating it is.

I currently do not know how the things will further evolve. Much depends if any better productivity or even quality could actually be achieved with the unusually high level of micromanagement. The answer to this may differ for the different companies, cultures and software products.

Answer 9

It's not normal and it would annoy me. Sooner or later, as the project grows, the software architect will become a huge, expensive bottleneck if he or she insists on going over everyone's code.

If it were me, I'd be asked to move to a project where you have more autonomy. If that doesn't work, it's a seller's market. Don't be afraid to hop.

Having said that, ask him how long he plans on doing that and when would he or she expect to give you more autonomy. Maybe he or she is just seeing if you are competent and it's temporary.