09-10-2015
The most common problem I have seen in software projects that don’t have a responsible, capable, and experienced architect is that those projects tend to be very messy.
Most such projects are filled with pretty much all technologies and libraries that were popular during the projects life time.
The main reason behind this problem is:
Software developers get blown away by the overwhelming amount of new products that reaches the industry everyday.
Recent booms in software industry has made many software library vendors as well as software related writers who promotes these new libraries and products.
They talk about “what” but hide “where” and “when”
For some reason (I believe it’s the competition among them) these technical writers (a.k.a. bloggers, geeks, etc…) fail to include thorough information about WHERE and WHEN each concept or library can make an improvement to a software project.
The only message you can see in most sites and reviews is, “hey, this is a really cool library and you should use it”.
Most developers fall in:
According to my experience most developers, regardless of their technical expertise, have not trained themselves on decision making skills.
Therefore developers are under constant pressure to implement these “cool stuff” into their projects.
This is where you come in:
As a technical leader it is important that you maintain an open atmosphere in your team encouraging your developers to bring in ideas and new suggestions to use new things.
At the same time, as a strong architect you need to measure all potential benefits of these new suggestions and make a judgement with respect to following factors:
- Implementation cost – how much effort will it cost to introduce this.
- Validity – validate if your project would actually benefit from this change or if the benefits are minuscule, or even simply theoretical.
Your past experience should indicate whether it’s a good idea by conceptually applying it to your project.
The deference between an architect and a skilled developer is that the architect can visualize implementations and changes without having to try and fail.
Know how to say No!
It is important that you know how to explain-away wrong suggestions without making your important developers disappointed.
I Learnt Today 