How does a Software Architect get his designs programmed?

Question

Furthering my previous question about what an SA does, I'd like to know how SA's usually manage the developers under them. Is it:

• a manual process, where they meet with developers to make them understand the design
• semi automatic, where they draw diagrams that mostly suffice to explain the code to developers
• fully automatic, where they only draw UML/Class Designs and the developers must write the program all by themselves?

And also, when managing multiple developers, how are the jobs distributed?

• is each developer given a part of the same planned feature
• or each developer allowed to do whatever he/she understands of the planned features in the software
• or they are spoon fed class by class, function by function, exactly what must be written?

Answer 1

IMO it must be a "manual process", with meetings and stuff. If everything was so clear that you could do it "fully automatic", you could let a program do the automatic conversion from UML to code, so effectively the architect would become a programmer with UML as the language of his choice. Well, I know there are code generators that can do that to some point... but I doubt any reasonable person would try to do that for the whole of a seriously sized project.

Answer 2

Have you listened to the Stackoverflow podcast and ascertained Joel and Jeff's position on Software Architecture?

I'd classify what you are describing as a Senior/Lead Developer.

I'd hate to be on a team that is spoon feed classes. If you are spoon feeding functions you might was well fire the team and write the code. And collect a large bonus at the end. Seriously, unless it was an army of junior developers fresh off the college nipple, what's the point of being a developer if you don't have leeway to be creative? Anyway, who in their right mind could keep all the classes in a large application straight. Diagrams and UML do help, but you get to a point where it's too much for one person.

When I assigned tasks to other developers, it would depend on two things: their availability and skill set. It also depends if the work is on the critical path or not as whether I assign a task to a developer. A less reliable developer wouldn't get tasks on the critical path, as a more reliable developer would.

When I design software I do it as a team. Each member of the team contributes to the design regardless of their skill level. This creates buy in for each member of the team. They are now a part of something and has intrinsic motivation to see the success of the project. Each member brings experience (or lack of) to the table that no one else has, it's what makes developers valuable: Their Experience.

I've seen good solutions become great. I've seen solutions created by experienced( 10 to 20 years) developers/architects, shot to pieces by junior and mid level developers, merely by the naive questions brought into the light.

If your project is large and interfaces with multiple systems across a vast company chasm, then you will need to bring in people who understand the vast intricacies of the system. On the same token this person isn't likely to have the skill set to design a solution at a class or function level.

In regards to doling out task it depends on what paradigm you use (SCRUM, LEAN Kanban). SCRUM has daily meetings, typically tasks are pushed onto the team. Estimates are given. Lean on the other hand uses a pull system. There is a queue of tasks. When a developer is done, they "pull" the next task from the queue.

There is a DotNetRocks episode that talks about how to manage large teams. From what I remember critical mass is 7 to 8 team members to each Project Manager/Lead Developer. If you are in charge a large number of projects, then you would meet with each Project Manager/Lead Developer to get a status update and give them tasks to dole out.

Answer 3

It may depend on the size of the enterprise. For a large one, a Software Architect is:

• not the only architect (there are software and business architects in charge of designing the specifications, meaning they do not code and have a very different mindset)
• not project manager, but rather in charge of designing the different applications of a large system, effectively translating the functional specifications into a technical set of applications.

Managing developers is another process which varies from project to projects.

Software Architects will be more concerned with coherency of the development both:

• internal to the new system (does the developers follows the specifications, with good technicals solutions)
• external to the new system (since it usually will replace/evolve a legacy one, which can hardly afford to stand still during the development of the new one. That means the evolutions of the legacy better be more or less aligned with and taken into account by the new system.)

Answer 4

I imagine it often goes like this: the software architect makes his design and then the developers do whatever they want.

Answer 5

This is all a bit subjective and varies greatly on the scope and constraints of individual projects, as well as the style of the architect/manager. However, my ideal scenario (as a soon-to-be-software-engineer (but yes I do have experience as a lead developer)) is to have the implementation fully automated.

Before any UML is drawn or any design thought about, an SA should have written a complete, unambiguous specification of their client's requirements. When the design is produced, it should be traceable back to the specification. This not only helps with a clean design, but also helps future users of the design documentation understand it, as they can clearly see what a design component aims to achieve. In a perfect world, the design artifacts will be formal enough to be able to hand to some theoretical tool which implements them, basically your source code is a high level design of the system. These days we get by by giving them to humans. UML et al will often be accompanied by plain text explaining the design.

But who really has time for all that...

As for distributing the work load. I'd assign each feature/module to a separate developer/small team. The real aim would be to make sure each developer can test their work in isolation so they're not waiting for others or disturbing each other. Pretty much aim for the interfaces in the design as your boundaries of responsibility.