Technical design

Question

Lately the company hired a technical analyst for the dev team.
For all new projects it's his tasks to analyse the clients demands and come up with an analysis design that can be used as a starting base for actual development.

Now apparently this techincal design will contain some sort of class diagram that should be used as a guide by the developer to contruct the classes/interfaces and provides an overview of how these objects should interact with each other.
This bugs me in a way, feels like he wants to put too much restrictions on the development side of the project.

IMO this will reduce the freedom of a developer and will just take all the coding fun away.
Has a technical analyst the right to impose such design ?

Answer 1

This is like saying that hiring an architect to draw the blueprint for a house takes away all the freedom and "fun" the mason has building it. :)

Answer 2

Are you sure this analyst isn't an architect or technical team lead? Given what you describe, it seems like the new guy would be one of those kind of roles so yes he has the right to impose such design as he is the interface to the clients and in a way is the stakeholder for the project.

Answer 3

When they hire someone as an architect, or a technical analyst, it is because your company has (correctly, or incorrectly) identified what they feel is an area in which there could be improvement. They have decided that having the developers create designs on the fly was not what they wanted to do, that they would prefer to have a technical analyst present a unified structure.

As someone who has worked in support, this is an area which is commonly overlooked. Every developer feels that their design is both correct, and better than anything anyone else coudl come up with. And while their designs are probably very strong, there will be NO consistency among projects. This dramatically intereferes with resourcing to the point that ramping people onto a project involves a period of time which is counter productive because they are breaking builds because they don't understand the obscure architecture created by the original dev. Adding some constraints on the devs is sometimes a good thing, because it keeps them from getting too far from what is reasonable.

Second of all, assuming this analyst has industry experience, and he has worked on many projects, then he would be aware of which class formations, or technical designs lead to trouble and which ones usually turn out simpler. So the great new idea that you have that he feels is too fancy, chances are he's seen it before, and it ended in disaster. Or shiny new technology that you love and want to work with, she shows you something less elegant, and 100x more reliable.

I say this as someone who is NOT the technical designer, but someone who has needed to be reigned in a few times and every time, without fail, the technical analyst has made the correct call, even if I didn't understand it until after the fact.

Last but not least, since you are both employees of the same company, you each have whatever rights your shared bosses give you.

Answer 4

There is a difference between suggesting a design and mandating a design. No up-front design will ever be 100% perfect so every design will have to be modified during development. devinb is right, however, that there is value in designing before building. I firmly believe that there is a happy medium between complete up-front design like in the bad old days of waterfall development and the complete abandonment of design practiced by some of the most hard-core Agilists. Martin Fowler's article "Is Design Dead" holds a lot of truth in this respect. If your organization uses the new designer to help facilitate a culture of Evolutionary Design then you work for a smart, forward-thinking organization and you are lucky. If your organization uses the new designer to force you into a box from which you have no flexibility then you are in for a rough ride.

Answer 5

There are a number of nasty little details around Mez's post we don't get to see, that would define the company's need more completely..

From personal experience I can say that most teams don't have a lot of great designers.. although they may have a number of great coders. Programming is a very detailed occupation, and being a great designer many times means divorcing yourself from the details so that you can see the big picture. That combination of skills I just don't see much.

Another thing to keep in mind is that folks that act as overall technical leaders, if they are good, will be looking to make sure that enough of the system is explored so that you've wrung out the surprises that inevitably lurk. You can never root them all out, but that is the real job for a technical leader. Identify the gaps and make sure those gaps get covered. Ideally, your leader is looking to make sure someone owns the solution to the gaps.. not just himself. Teamwork in design is just as critical to success in large projects as teamwork in coding. Technical leads that approach the problem as a team problem find the most success. Those that ignore the team dynamic in design do so at their own peril (and trust me, I've seen this a lot.. its NOT pretty).

So the real question is, what type of technical leader are we talking about, and how effective is the company at organizing/delivering large projects? Difficult to know from one post.