To code or not to code? The software architect's dilemma
Software architects are often asked this question
"So now that you are an architect you must have stopped coding, right?"
As a software architect for the past 3 years I've never felt the need to give up coding completely. It's true that more of your time is devoted to understanding the customers need and translating it into both software requirements and an architecture that can be consumed by designers and developers.
However, I strongly believe that coding is one skill that should never leave your arsenal and I'll explain the various instances when your coding skills will prove useful if not essential!
Prototyping
Many if not all complex software projects begin with some user needs that have never been implemented before. In such situations it's requisite that one or prototypes be created to determine if a feasible solution exists or not. I strongly believe that it is the duty of the Architect to take up at least a few of these prototypes, since the result of the prototype will strongly dictate the architecture of the product and also the experience of the architect will play a role in determining the correct criteria for choosing the winning prototype.
Regular Implementation
Although many architects refrain from being involved in coding during the implementation phase nothing stops you from getting your hands dirty if the team demands it. This is extremely useful if existing developers are expected to learn and improve their coding skills from an experienced coder. Also, in a test driven environment often new developers struggle to define the right unit tests and an experienced mind certainly does help.
Defect Fixing
This is where the architect should exercise caution. Again, if the team demands it, the architect can and should lend a hand while fixing defects. But it is proven on several occasions that defect fixing is one of the quickest ways for a developer to learn the design of any feature. And this is where the architect should ensure that the complex features are not taken up by himself/herself but rather left to someone who is in dire need to learn that design.
“Upskilling”
This term is coined very often in a corporate environment. It refers to improving the skills of employees so that they are better at doing what they do. Now, for an architect this could include gaining certifications or architecture related trainings. But an important part of upskilling is to learn new and upcoming technologies so that the next architecture will solve problems using the latest and often better techniques. And it is during the course of this upskilling that architects get to use their coding skills and keep their fingers tap friendly.
These are my views on why an architect should still code and how. Hope this made sense to you.
Cheers!
However, I strongly believe that coding is one skill that should never leave your arsenal and I'll explain the various instances when your coding skills will prove useful if not essential!Prototyping
Many if not all complex software projects begin with some user needs that have never been implemented before. In such situations it's requisite that one or prototypes be created to determine if a feasible solution exists or not. I strongly believe that it is the duty of the Architect to take up at least a few of these prototypes, since the result of the prototype will strongly dictate the architecture of the product and also the experience of the architect will play a role in determining the correct criteria for choosing the winning prototype.
Regular Implementation
Although many architects refrain from being involved in coding during the implementation phase nothing stops you from getting your hands dirty if the team demands it. This is extremely useful if existing developers are expected to learn and improve their coding skills from an experienced coder. Also, in a test driven environment often new developers struggle to define the right unit tests and an experienced mind certainly does help.
Defect Fixing
This is where the architect should exercise caution. Again, if the team demands it, the architect can and should lend a hand while fixing defects. But it is proven on several occasions that defect fixing is one of the quickest ways for a developer to learn the design of any feature. And this is where the architect should ensure that the complex features are not taken up by himself/herself but rather left to someone who is in dire need to learn that design.
“Upskilling”
This term is coined very often in a corporate environment. It refers to improving the skills of employees so that they are better at doing what they do. Now, for an architect this could include gaining certifications or architecture related trainings. But an important part of upskilling is to learn new and upcoming technologies so that the next architecture will solve problems using the latest and often better techniques. And it is during the course of this upskilling that architects get to use their coding skills and keep their fingers tap friendly.
These are my views on why an architect should still code and how. Hope this made sense to you.
Cheers!
Comments