What’s my job?


Last months Dr. Dobbs has an interesting article on the changing face of software development jobs which rings true to me.  As the software development discipline matures you might expect the roles to become better defined and specialized.  Just like Eskimos have many words that all mean “snow”, in the software development world we have many names for what amounts to “developer”: Developer, Web Developer, Integration Developer, Build Facilitator  Developer, Architect, Developer in Test, Test Engineer, Lab Manager, Stress Developer, Performance Developer, Test Automation Writer, Test Automation Runner, Program Manager, Release Program manager, Feature Program Manager, Community Program Manager, etc the list goes on and do…  While I am a huge fan of the economies of scale that you can get by specializing, it is not without costs.  


 


Whenever a software\designs have to be handed off between groups there is inherently some amount of overhead and the “us\them” problem has room to take root.  As a result the industry is moving to a more agile development model where we need to staff small teams that can deliver solutions end-to-end… In such teams we do certainly need experts, but we also need great generalists that are able to take on whatever role they need to get the job done.  To that extent hard lines between the different roles (test, developer, program manager) don’t help.


 


Here is to a day when we can stop hearing:


“The test team is behind in writing automation tests “


“The development team writes buggy code”


“Xxx is not my job”


 


And start hearing:


“We finished writing automation tests together as we completed developing the feature”


“Together we assured the quality of the code as it was written”


“We shipped the right product on time!”


 


 


What do you think?  What is the most specialized role in software development you have seen?  Was it worth it?

Comments (15)

  1. AlanM says:

    I believe that titles are largely meaningless except as a means of distinguishing one person’s responsibility on a specific project from another’s. Your Software Design Engineer is my Programmer/Analyst, my Solutions Architect is your Program Manager, your Software Development Lead does what it takes my "experts" in databases, code design, and testing to accomplish together, all of whom are titled "Senior Programmers" on my org chart.

    Goodness knows my title has made no impact on my hireability as a consultant. As long as it has adjectives like "Senior" or "Lead" or "Chief" (enough to keep my resume from being tossed), most hiring managers tend to look mostly for what it is I can do based on work history and accomplishments. Unless I can write "Chief Software Architect of Microsoft" (a title that’s currently filled by someone whose name escapes me at the moment), I don’t expect a title to do much to describe what I have done or can do.

    Now, if there were a way to better describe relevant skills. For example, I think I’m not half-bad at designing business-object-model interfaces and semantics, though I am probably not as fast as others at actually developing production-quality code to implement them. What title would I get? "Architect"? "Program Manager"? "Analyst"? What if there was an agreed-upon general skill title, like "Business Object Design (not DesignER)" which could be one of several skills I would advertise? It would overlap other skills, such as "Enterprise Information Service Integration," "Test-based Design," or "Windows Forms Application," most (if not all) would be associated with largely agreed-upon levels, such as "Novice," "Apprentice," and "Expert." I’d stop there, because after that, it could be splitting hairs and one-up-manship.

  2. davkean says:

    One thing that I was really surprised about when I joined Microsoft was that there was a really big distinction between the pm, test and developer roles. In my organization (devdiv), the test and devs were working in different trees (and often different branches!), with the test tree typically out-of-sync by a couple of months with the dev’s tree.

    However, now with the introduction of feature teams throughout dev/div for Orcas, this is no longer the case (at least for my team, anyway). Dev and test are in the same branch/tree, and both dev and test write code/tests. We are now easily hitting both code, coverage and testing goals.

    Although I don’t mind have the distinction between the roles, I think it could breed the whole ‘this is not my job’ attitude, but truthfully I haven’t yet seen this.

  3. Julio Casal says:

    Well, I have always thought that specialization is a key element on a development team. In the development teams that I have worked there have not been a clear specialization, more than defining a Project Manager a lot of developers. In that environment I have seen how lots of people take too much time to complete their tasks, and I think it is mainly because if everybody has to learn everything it is a complete waste of time. If I am a developer, why do I have to be a Transact SQL expert? If I am good at user interfaces, why do I have to deal with the complexities of a distributed system? If I I’m good at writing complex algorithms, why do I have to know the best way of testing an application?

    Although I have not had the opportunity of working in large specialized groups, I don’t think that having a team where everybody does everything would have any benefit.

  4. J.Marsch says:

    It seems to me that the number of disciplines that we pack under the term "development" grows every year.  I come from the background of having been a "great generalist", but for how long is it reasonble to continue with generalization?

    How general does a generalist have to be?

    Now we have multiple viable platforms (Linux/Windows).  Lets assume that we are talking about a "Windows Generalist" (just because I don’t know enough about Linux/xNix to respond effectively <g>)

    Now to be a generalist, you have to know: Winforms, Asp.net, WPF, WCF, WWF, AJAX,javascript on IE, javascript on Firefox, SQL, Enterprise Services, Active Directory, IIS,  XML, MSBuild, How to write secure code, UI design, (like really good, ergonomic UI design, not just making forms), "artistic" graphic design (seen the Vista stuff yet?), and about a gazillion more things that I haven’t listed, some of these are contained topics, and some are very broad.

    As each of these topics becomes more mature and more broad, it seems that the generalist will need to make a deeper investment in each.

    If I look to the sciences, medicine, and engineering, each of those professions encountered similar issues as they grew, and in each case the solution was specialization.  (you probably don’t want a foot doctor doing brain surgery, and you probably don’t want a practicing EE designing dams and bridges)

    I think that we are going to see more specialization as we increase the scope of what it means to develop software.

    As for keeping groups small and agile (avoiding the "testing hasn’t built our tests yet, etc), maybe instead of building a small team of "jack of all trades, masters of none", we will build small, multidisciplinary teams, where each member is responsible to and contributes his or her expertise to the product.

  5. AlanM says:

    I agree — but I don’t think we’ve evolved the field to the point where job/position titles are standard. Skill titles, however, are pretty close.

    Job title: "Doctor" ≈ "Developer"

    Specialist job title: "Chief Neurosurgeon" ≈ "Chief Software Architect"

    Another title: "Oncology Resident Doctor" ≈ "Apprentice Communications Developer"

    What does "Doctor" do? A zillion things, but, like "Developer," we basically agree on the concept.

    What does "Chief Neurosurgeon" do? It’s more specialized than "Doctor" but not much more useful other than in describing a very broad concept within the realm of "Doctor," though we can be pretty sure the neurosurgeon isn’t applying splints to broken legs. Likewise, we are reasonably certain that the Chief Software Architect doesn’t spend much time writing unit tests. But two different chief neurosurgeons can be performing greatly different functions within a hospital, even exercising rather different skills. The skill of surgery will no doubt be exercised, as general system design will be exercised by the software architect.

    And "Oncology Resident" gives us both an idea of specialization and the level of expertise. As with any career field, it doesn’t do much to describe the innate talents of this doctor, but it does tell us something about the depth of experiences.

    Where things get useful is in describing a skill that must be mastered to reach an agreed-upon level of proficiency. Would I let my oncological "specialist" perform an excisional biopsy on my child? Only if she convinced me that she had mastered that skill. For that matter, I’d let my neurosurgeon do it if my neurosurgeon had also mastered that skill.

    A small group of doctors, whether they’re somewhat specialized or not, can do a very wide variety of tasks when they travel to regions of the world without medical services. Obviously a very-highly specialized doctor would be out of place there. But most doctors in such a situation could adapt, learn on the spot, and teach each other. It depends on the circumstance. Naturally, the same doctors could pursue deeper specializations at home. The question is: given a specific medical challenge, can they exercise one or more skills and succeed?

    With software developers, I don’t care what your title is, and I don’t care how well you’ve studied the state of the art (specifically, I don’t give a rats a** if you can name every pattern in the GoF books backwards). I do care that you can write a good unit test, that you can design cohesive classes, that you can optimize network utilization, that you can appropriately normalize a schema, that you can create a UI that doesn’t make users feel stupid, that you are familiar with the capabilities in the .NET BCL, and so on. Not all skills must be in the same person, as long as I have coverage for all within the whole team. I think these skills, more than positions, need titles which we can agree upon, and probably skill levels which we can agree upon.

  6. James Saull says:

    I agree, so how come VSTS seems to be seriously increasing the cost to individuals in pan-"developer" roles? This is going to increasingly become a real impediment to such individuals and teams who really need Team Suite. Before the days of NUnit, NCover, N* et al. it might have been possible to justify this value-add-cost but that just is not the case anymore and it is just a plain old impediment.

  7. Matt Davis says:

    Sorry- first thing that came to my mind:

    BOB SLYDELL

    So what you do is you take the specifications from the customers and

    you bring them down to the software engineers?

    TOM

    That, that’s right.

    BOB PORTER

    Well, then I gotta ask, then why can’t the customers just take the

    specifications directly to the software people, huh?

    TOM

    Well, uh, uh, uh, because, uh, engineers are not good at dealing with

    customers.

    BOB SLYDELL

    You physically take the specs from the customer?

    TOM

    Well, no, my, my secretary does that, or, or the fax.

    BOB SLYDELL

    Ah.

    BOB PORTER

    Then you must physically bring them to the software people.

    TOM

    Well…no. Yeah, I mean, sometimes.

    BOB SLYDELL

    Well, what would you say… you do here?

    TOM

    Well, look, I already told you. I deal with the goddamn customers so

    the engineers don’t have to!! I have people skills!! I am good at

    dealing with people!!! Can’t you understand that?!? WHAT THE HELL IS

    WRONG WITH YOU PEOPLE?!!!!!!!

  8. BradA says:

    Ahh — yes… How could I forget to reference Office Space (http://www.imdb.com/title/tt0151804/) 😉

  9. carlclarke says:

    I think that software engineering / development is much more difficult to define and label than say medicine or engineering. Medicine and engineering both benefit from hundreds of years of hard earned experience and practice, software engineering is still relatively young.

    Agile ideas bring an element of teamwork and shared responsibility into the process that is sadly often missing. I believe that part of the reason for the software industry earning a poor reputation (and this is what drives us to find new ways to do things) is that there are too many self proclaimed ‘experts’. These seemingly unchallengable experts end up leading companies/projects/teams towards costly mistakes, unable to change their direction for fear of hurting their egos.

    I believe that we need experts – but not the noisly, self proclaimed kind, we need the solid, experienced, quietly confident kind.

  10. hello everyone, I’d say I only have 3 years of exprience with Microsoft technologies. I have started with .net since 1.0 beta version, and Now work on asp.net 2.0, and love it.

    about the developper part, in my opinion, it is about to change with the coming of windows vista. in fact, its architecture, built on the concept of services and layes, it might get to the point that a multitude of technologies will be integrated in one platform, only to make every tier more scalable than ever.

    with the coming of xaml, development against flash using flash remoting, the stability of .net framework with object oriented languages.

    I’d say that some new roles are about to become more in demand and more productive than before: UI developer, Enterprise Services Developer, Web Services Developer, DataBase Developer (thanks to the clr in sql 2005). I think developer titles should be more based on the architecture we follow for our systems.

    Above this, we always have, architects, product managers, program mangers, project managers etc.

  11. Richard says:

    > Just like Eskimos have many words that all mean “snow”

    Don’t know what the guys at Yahoo are on with that Q&A, but this is the base snowclone (see the Language Log for details: http://itre.cis.upenn.edu/~myl/languagelog/archives/000350.html, and for specifics of this case http://en.wikipedia.org/wiki/Eskimo_words_for_snow).

    English would have been a better language to use here, which has just about as many words for snow as the Eskimos do.