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
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
2 Comments:
I think there is room for some specialization in order to have "best of the breed" solution in your business area.
You would like to have top notch graphics artist in your game development team to make your game more appealing. Still the team would consist of some overlapping skills in the pure programming side of the things, like guys who can do Java, Flash, SQL, OS stuff.
I just want to throw Corey's blog into this as I found it interesting: http://leansoftwareengineering.com/2008/02/10/division-of-labor-in-lean-software-development-workflows/
I am not saying you are completely wrong, just not agreeing that specialization is as bad as I interpreted from this post. Maybe I just picked wrong business area for my example as the backend provides more possibilities for generalists.
By
Marko Taipale, at June 08, 2009 9:54 AM
It is OK to develop specialized deep knowledge relevant to the work, that can be applied in teamwork.
This is different from narrow/overspecialized organizational roles and responsibilities, which lead to complicated organization and problems.
By
Ari Tikka, at August 04, 2009 8:52 PM
Post a Comment
<< Home