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
Anonymous
June 04, 2006
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.Anonymous
June 04, 2006
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.Anonymous
June 04, 2006
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.Anonymous
June 05, 2006
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.Anonymous
June 05, 2006
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.Anonymous
June 05, 2006
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.Anonymous
June 05, 2006
The comment has been removedAnonymous
June 05, 2006
Ahh -- yes... How could I forget to reference Office Space (http://www.imdb.com/title/tt0151804/) ;-)Anonymous
June 05, 2006
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.Anonymous
June 06, 2006
The comment has been removedAnonymous
June 06, 2006
The comment has been removedAnonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=16858Anonymous
June 07, 2009
PingBack from http://besteyecreamsite.info/story.php?id=1571Anonymous
June 08, 2009
PingBack from http://toenailfungusite.info/story.php?id=2685Anonymous
June 08, 2009
PingBack from http://quickdietsite.info/story.php?id=4652