Skip to main content

Is pigeonholing people into specific disciplines bad?

Posted by simongbrown on September 10, 2003 at 1:45 PM PDT

With traditional development methodologies, it was easy. You'd start some requirements capture, follow on to analysis, then design, implementation, testing and deployment. Typically you'd have a few people in at the start and ramp up the team during the design and implementation phases, with several members of the team performing many of the tasks on the project right from the start. Fast-forward to today and it can be a completely different story.

Take the Rational Unified Process (RUP), for example. While RUP still has the same phases (albeit they are named differently), the process adds an extra dimension. RUP introduces the concept of disciplines, and during any phase you have each discipline still working on their activities. After all, RUP is an iterative process. For example, while the majority of the work undertaken during the construction phase is implementation, the analysis and design discipline might still be doing some A&D work in parallel. Although I like iterative processes, I do have an issue with the degree to which some people want to pigeonhole team members into a single discipline.

Since I like to get my hands dirty with development, I made it known that I would like to be involved with the implementation of the project that I'm currently working on. For this reason, I've been placed in the implementation discipline. This is great news, but then why do some people think that the implementation team can't do analysis and design? And why can't some of the A&D team help out with implementation? In fact, some would say that architects can't help with design. What benefit does pigeonholing people into a single discipline achieve? Okay, you may have experts in a specific discipline. Business analysts are a great example. High level architects are another. But what about the main body of the team?

Of course, there will always be people that only want to do analysis, design, implementation or whatever. However, isn't having a broad range of software engineering skills better? Having interviewed a handful of potential employees over the summer, I saw an alarming number that have only been involved in a single discipline, and with most of these it was implementation. Traditional development methodologies seemed to promote a broad software engineering skillset