Simon Brown's Blog

Is pigeonholing people into specific disciplines bad?

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 � something that I'm not convinced processes like RUP do. What's happened to people following through work from analysis and design to implementation and testing? Isn't this damaging for people's careers? Are projects getting the most out of the people? What do you think?

Comments

• Pigeon holing doesn't work
  I'd argue that pigeonholing is counterproductive. I'd also argue that people CAN'T be as pigeonholed as they, or their pigeonholers, think.

  Starting with the first point: A reasonable question is, how can you design or architect a system if you don't have an idea of what it will take to implement the system? With technology changing so quickly, if you don't keep getting your hands dirty in implementation, the hands-on development skills you once had become outdated, and your architecture or design may not be appropriate for the tools and systems that will be used to implement it.

  Unfortunately, this happens all the time. My current project had an "architect" who admitted that he was not a very strong programmer (how he got to be an architect is anybody's guess), yet he was called on to write code anyway. And both his design and his code should his lack of programming skill. The design was overly complex, and the implementation used a morase of code when there were obvious straightforward approaches available. Personally, I think many architects are destined to produce inappropriate and overly complex designs because that's how they demonstrate their worth, but that's the subject for another debate.

  Aside from being unfavorable, pigeonholing is basically impossible. Martin Fowler argues, and I agree, in his essay, "The New Methodologies" that implementation/development/coding/whatever you want to call it IS design. Construction is no more than running the compiler and linker, and involves no creative thought. Development is design, and is thought intensive, and is not a mere mechanical exercise. That, again, is the subject for another debate; Fowler's essay does an especially good job of addressing it.

  So, your "implementors" are going to be designing at some level, whether you admit it or not. So you'll be best off if you come to terms with that, and help ensure that they have at least an introduction to design. And while you're at it, if having an architect on your project is en vogue, make sure that architect knows how to develop.

  Posted by: jimothy on September 11, 2003 at 08:46 AM

• Traditional process?
  What do you mean by 'traditional processes'? The traditional chaotic process, where programmers have to design web pages, or web designers must learn JSP, or or architects must be also programming gurus to have the programmers' respect?

  I'm not saying it's not good to have developers have a notion of all phases of development, it is. It is better for both the developer, that can use this knowledge to improve his skills, and the project, that gains from the synchronism of the team.

  A good professional will seek for more knowledge and experience, in both his area and others, even if he doesn't go much deep in the areas that aren't of his expertise. It gives him a broad view of the process, and the capacity of doing his own job better, tuned with the team.

  But you can't blame the process for poor professionals. The good managers and architects I know, do study the technological platform the systems they will develop wil use, but they don't sit to code. They have more important things to do than writing getters and setters. They study only to the extent they need to know, to make programmers do the dirty work. They don't study all areas because the development process requires them to do it, they study because they want to became better professionals. And that is the only way to make better professionals, to have them want to improve themselves.

  A processes that forces developers to do everything will just produce systems with an average/poor design, average/poor code, and average/poor user interface.

  Posted by: ronaldtm on September 12, 2003 at 04:43 PM

• Pigeon holing doesn't work
  I agree with your statement that architects must know the technologies they are dealing with. Sure, you can get so far, but generally I don't think that you can go to a level of detail that is in any way useful to those that are going to design and implement the system. For example, I certainly wouldn't like to be held responsible for the architecture of a .NET system when I don't even know .NET!

  Posted by: simongbrown on September 15, 2003 at 07:25 AM

• Traditional process?
  By traditional processes, I'm referring to processes like waterfall where (typically) the same members of the team tend to take a project through from inception to completion. What I'm finding is that with processes like RUP, typically people are starting to get pigeonholed into just doing a single type of work, and that each of these disciplines does their work and hands it over to the next. Again, this is just my experience, but it seems to be the case that there isn't a consistent thread between the various phases of the project. Work just gets handed "over the fence" onto the next team. In doing so, people get more and more pigeonholed into only doing design, or only doing development. This does happen with waterfall projects, but I think I'm seeing it more with iterative projects. From this, I think that people are losing experience of the wider development activities, and it's this that is possibly damaging. I'm not saying that developers should do everything, but there has to be a happy medium where they get at least some exposure to other tasks during the project lifecycle.

  Posted by: simongbrown on September 15, 2003 at 07:44 AM

• Pigeonholding isn't part of the process
  Most, maybe all, of the process books I've read, including RUP, tend to point out that the "roles" that execute the activities can be played out by anyone. Some state the point as an afterthought, some more forcefully.

  
  One person might have many roles, analyst early, then architect, then implementor, etc. Several people might play one role, such as when several architects work on a chunk of key design work. Who plays what role might change as the project progresses.

  The pigeonholing tends to be done by management or even the individual themselves if they happen to really like a particular role (or are afraid of other roles). Management likes titles, Bob the "analyst" or Jim the "implementor", whatever. They can look at their tasks and org chart and start dishing out pieces. It complicates the MS Project spreadsheet when people can do more than one thing or switch roles.

  I'm being somewhat sarcastic, but the kernel of truth there is that I don't think pigeonholing has anything to do with the process. People get pigeonholed as the "installer guy" or "scripting guru", etc, etc. It's nice to be an expert in something, but most everyone also wants to stretch their wings over time and try other areas. That's strictly a people management issue, not a process issue.

  Posted by: ckessel on September 15, 2003 at 11:54 AM

• Pigeonholding isn't part of the process
  I agree - it's certainly a management issue, but having a process that defines so many roles just complicates things. As you said, people don't generally understand the fact the one person can undertake many roles throughout the project.

  Posted by: simongbrown on September 16, 2003 at 02:02 AM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: 9uf009 on December 13, 2007 at 04:12 PM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 05:09 PM

This work is licensed under a Creative Commons License.