Ask HN: Who is a software architect?
Given that, I wanted to know what a good software architect actually is? What they actually do?
Internet searches give me Jargon'ish definitions.
Given that, I wanted to know what a good software architect actually is? What they actually do?
Internet searches give me Jargon'ish definitions.
I spend a lot of time leading the planning of new features for implementation. This includes, in many cases, going through the requirements/specifications documents and, as precisely as possible, laying out what needs to be done to implement each feature. Since most of our applications are MVC-patterned database-backed web applications, I start off by defining the SQL schema, down to writing the SQL evolutions. Since the primary data structures in any given application mimic the schema, the data structures usually follow directly from the schema and are pretty easy to clearly define. Then, having created the schema/model structures, it becomes a matter of defining exactly what functions/methods need to be written, defining the function signature of each function (we work primarily in Scala). I leave the function signatures as stubs to be implemented by our developers. Then I create cards for our Kanban board. Usually I create one card per unit of functionality (along with complete unit tests) for this functionality. I also create separate sprints for integration test of each piece of functionality. I put them in the Backlog and assign them to each of our programmers. I then code along with my team to rip through the cards as quickly and correctly as we can, hoping to honor my design as much as possible while making any necessary changes when it turns out the implementation we had planned is either too difficult or complex, or will not solve the problem adequately.
The planning process really serves to pre-answer as many questions as possible that would otherwise come up during the course of implementing a user story or feature. I go down as fine-grained into the detail of what needs to be done as possible without actually writing the implementation, so that developers have as few questions as possible when they actually sit down to write the code. The more questions we have pre-answered, the more clearly defined our follow-up questions will be, the ones we encounter on the way to implementing our design.
I hope this helps.