Why specialization in Software development is bad for business
Specialization in software development hurts our business! I'm not talking about the kind of specialization that leads to spend some more time in one area than in others. I'm talking about the specialization that leads us to have Database Administrators (DBA) or Database Designers (DBD) or Kernel programmers that don't do anything else!
Take the example of a DBA. The thought that a DBA would not need to know about file systems is simply ludicrous. A DBA cannot do a very good job if he only knows about SQL, stored procedures and other DB characteristics. The competent DBA will need to know about file systems where the data is ultimately stored, about the Operating System which will ultimately ensure that the data is safely kept in memory or flushed to disk, about data structures and algorithms that will inform his decisions on how to configure the DB engine, etc.
The list goes on and on. This is not to say that we don't need people with particular strengths in some areas (called "generalizing specialists"). But this means that specialization as is practiced by many software organizations around the world (banks, finance, large consulting companies, large SW companies, etc.) is a myth and in the example of our DBA completely counter-productive to the point that it actively hurts our business (assuming software can have an impact in the business).
It's illuminating when you look at which software organizations actually implement and defend this specialization strategy: organizations that don't understand software and that it is a science/art in itself. There organizations tend to be large (even if some small ones do the same mistake) and run by people that don't have a background in software development themselves.
Specialization is for insects! If you develop software be aware that you need to understand a lot more then the narrow field in which you have "specialized".
Here's a challenge for you: what's the most dysfunctional specialization story you've encountered in your professional life? Care to share it? Writer your story in the comments below.
at
15:42
|
2 comments
Take the example of a DBA. The thought that a DBA would not need to know about file systems is simply ludicrous. A DBA cannot do a very good job if he only knows about SQL, stored procedures and other DB characteristics. The competent DBA will need to know about file systems where the data is ultimately stored, about the Operating System which will ultimately ensure that the data is safely kept in memory or flushed to disk, about data structures and algorithms that will inform his decisions on how to configure the DB engine, etc.
The list goes on and on. This is not to say that we don't need people with particular strengths in some areas (called "generalizing specialists"). But this means that specialization as is practiced by many software organizations around the world (banks, finance, large consulting companies, large SW companies, etc.) is a myth and in the example of our DBA completely counter-productive to the point that it actively hurts our business (assuming software can have an impact in the business).
It's illuminating when you look at which software organizations actually implement and defend this specialization strategy: organizations that don't understand software and that it is a science/art in itself. There organizations tend to be large (even if some small ones do the same mistake) and run by people that don't have a background in software development themselves.
Specialization is for insects! If you develop software be aware that you need to understand a lot more then the narrow field in which you have "specialized".
Here's a challenge for you: what's the most dysfunctional specialization story you've encountered in your professional life? Care to share it? Writer your story in the comments below.
Labels: agile, coding, project management, project smells, roles, software development
RSS link