Alternative title: Are you willing to be pigeonholed by someone with a narrow view of the software industry?
I recently came across a post by Alan Snorkin which claims there are three types of people in software: computer scientists, programmers and developers. It’s pretty short and worth a read.
On the face of it the post seemed insightful. I could see myself as fitting best into the programmer category. But I fail to see the point of this kind of restrictive pigeonholing. It may appeal to recruiters and managers who percieve it makes their job easier – but beyond that it’s largely counterproductive.
The article exemplifies an observed insudtry-wide lack of enthusiasm for software architecture and engineering. It’s a wonder the author can stand upright, with his knees jerking like that. I responded, paraphrased here.
Remember that software engineering is the most immature of all engineering disciplines. We’ve been building bridges and buildings for centuries – chemical and electrical systems to a lesser extent. But modern software development has only existed for about 30 years.
Add to that the much higher growth rate in software relative to other engineered industries, and you start to understand the lack of widespread adoption of engineering in software. Software engineering is still evolving as new systems come along such as the Internet, distributed systems, cloud computing, social networking etc. Many programmers, developers, project managers, etc. will hesitate to adopt a certain architecture or expend resources to engineer a system when there is a very real possibility that all their work will be out of date in 2 years as something better has come along or the industry has moved on.
So why then is rigorous architecture so ingrained in other industries such as mechanical, electrical and civil engineering? It’s a necessity. Without engineering, projects fall apart. There are no real consequences if your toy Web 2.0 app falls apart – maybe some commercial losses. But what if your un-engineered application was a control system for a nuclear reactor? A building, a bridge, or a train signalling system? Ouch.
I’ve done a bit of research into Facebook’s architecture. There are some brilliant videos and their engineering notes blog which describe it in detail, especially their focus on scalability. Services such as Google and Facebook could not meet their load demands without a scalable architecture. This kind of architecture will not “evolve” out of a consensus – it has to be designed.
The attitude of “Architecture is not used, therefore it’s not needed” is counterproductive and will only serve to reinforce the already observed industry-wide skepticism about engineering in software.
What’s missing from the original post is the acknowledgement that people can fit into one of the three categories but still be bad at what they do. Not all programmers “write awesome code”. Not all computer scientists “have 31337 math skills”. Not all developers have awesome people skills.
I have experienced first hand the need for consistency in system design in programming, but the principle also applies to IT support. In projects without the discipline of clean, modularised architecture, programmers will often revert to worst practices. If they have the time, they might do some refactoring but in reality, in high pressure environments with looming deadlines and no architecture enforced by management, programmers will be expected to achieve their task as quickly as possible – and this is often at the expense of code quality and thorough testing.
