Hacker News new | past | comments | ask | show | jobs | submit login

For a manager, I agree. An architect should write the most complicated, not the least complicated, part of code. This is assuming that the architect is the most experienced developer on the team.

This doesn't include paper architects, which are pretty much salespeople.

I would like to hear other people's thoughts on this - this is the way that I have always handled projects.




I suppose whether or not I agree depends on what you mean by complicated: there's complexity of an algorithm implementation and there's complexity of program structure.

I would think that you'd want an architect to work on non-tight-loop, core-to-the-control flow complexity, and leave the optimization of tight loops and such to people with more time to focus on the details of that (eg, what processor is being used), and instead work on the complexity of the control/data flow abstractions, which is what he already knows the most about, having designed their architecture.

This also keeps his role as central organizer of the code and flow through it, rather than having his time sidetracked (partially) by other concerns.


That is how I have it as well. With our projects usually the architect would write the framework of the product at the beginning of project, almost being the only developer on the project.

As other developers start getting on the project he guides them where their code should live, and he start to disengage writing and serve more in a guiding role.


I see the architect role in software development pretty much the same as a architect of a building. He/she will be in charge of the big picture and let others do most of the implementation and deal with small details, unless it's a crucial detail that the construction workers/developers needs help on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: