5 min to read
Engineering in a Software Development Company
I used to work with banks and financial companies chiefly. In these institutions, it was natural to have two different streams viz. the software stream and the core business stream - be it banking, brokerage or whatever else. Of course besides these two there are other streams such as infrastructure, administration,HR etc.
The structure is a little different as expected in a software development company. Most of these companies have core development streams - engineering and architecture - along with other streams such as QA, SEPG, UI, Documentation etc.
This bifurcation of the software developers into architectural and engineering streams was of course nothing new. The engineers develop software and the architects - well they design and architect it. This makes sense since the architects are just experienced engineers. But what slowly started puzzling me and even now continues to do so in parts (though I am now reconciled with the main idea) is the dichotomy within the engineering group itself. According to me all engineers must evolve to become architects. An experienced engineer starts understanding the system better and one fine day should become good enough to architect it himself.
But it looks like I was quite naive in this expectation. Engineers seem to be divided into two camps viz. the wannabe managers and the wannabe architects. Most engineers seem to aspire to evolve into a management role rather than try understanding the technology or architecture. This in my view is due to the fact that software development is a hard activity and requires considerable investment of time. It is far easier to be a manager. Don’t get me wrong - I respect good managers but becoming a manager is definitely far easier than to evolve into a technically competent person. Besides, you would have all the power that goes with it. You control people and budget .. hmmm sounds great!
I am starting to see that most engineers become “non-technical” after serving as less a time as three years in the industry. From then on, they rely on the architects for all the “technical guidance”. They do not even think in terms of understanding technology. They know that someone, who has taken the time to understand it, would help them out. When they become team leads or project managers there is still less incentive for them to learn or keep pace with technology.
The net outcome is what we see in the industry - most software that is developed becomes obsolete at birth or within a very short span of time. Even if the software manages to exist for sometime, it would need a full team for maintenance. The poor souls, who have chosen the architecture stream, are left frustrated. They have no upward mobility since the management uses them for solving geeky problems and don’t incorporate any strategic feedback that they may have. They would be left grappling with core engineering problems that should not have existed in the first place. The engineers know that they created a mess. But they learn to be nimble footed and flee the scene before their bad software is brought home to them. Their mantra would be to evolve into a manager very quickly so that they don’t have to worry about the tedious problem of actually developing software.
Hence it is very hard to find competent architects in the industry. That is also the reason as to why most software developed by a software development company is of a bad quality - a very oxymoronic situation indeed! On the other hand, software developed by the IT department of a company whose field is not software, is more maintainable. This is because the software team there is responsible for maintaining the software too. Hence it is in their interest to write a well designed maintainable software. Due to this, most engineers in a non software development company tend to develop a technical bent of mind.
In the long run, this trend is going to manifest itself as a backlash against outsourcing. Why outsource something when you can do it better yourself?
It is imperative that software development companies realize this problem and act to make technical excellence a mandatory criterion for managers. In other words, there SHOULD NOT be two different paths - the engineering and the architect path. Every engineer must become technically competent to evolve to become a manager. There simply cannot be a “non technical growth path” in a software engineering stream. By encouraging technical excellence, the managers tend to become technical too and hence would be more disposed to rewarding others who share their technical aptitude and enthusiasm.
Think about it - Do you ever find a manager without any financial competence in a finance company? Or for that matter do you find anyone in any senior position in a manufacturing sector who does not know about manufacturing? Then why is it that most software managers have no clue about developing software? This situation is enough to drive us all nuts!
I have had bad experiences working with managers in so called expert software development companies. Oftentimes, my team was much more better and had to train their engineers only to see them being pulled out of the company within a year. The Indian flavor to this problem is that we try to get the whole thing done with a bunch of freshers straight out of college. I was recently involved in an assignment where a company’s inexperienced staff was augmented by people in an outsourced company. Everyone from the software development company came straight from a college. What are the chances of this kind of arrangement sustaining in the long run?
This situation has to change if software companies, as a breed, need to survive. At the risk of being tautological let me re-iterate what I am saying - By allowing only technical people to succeed in your company, you would make sure that the software that you produce is good. As simple as that!
Comments
Adit Bhiday: That sums it up pretty well. It would be interesting to find out as to which breed are rewarded more (compensation wise) in the long run - the Architects or the Managers.
Comments