Summary:
In this interview with Artima, Loren Corbridge, manager of Sybase's Eclipse-based IDE, talks about developers' increasing involvement in a variety of business and management tasks, such as data and business analysis, and about developers' changing roles in the enterprise.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: August 18, 2007 8:30 AM by
Ramdas
|
In this interview with Artima, Loren Corbridge, manager of Sybase's Eclipse-based IDE, talks about developers' increasing involvement in a variety of business and management tasks, such as data and business analysis, and about developers' changing roles in the enterprise: http://www.artima.com/lejava/articles/javaone_2007_loren_corbridge.htmlHow do you see your role changing in the coming years at your organization?
|
|
|
I am prevented from downloading MP3 files at work, so I apologize if my comment is out of context.
What Loren observes has been true since I got into the field around 1992, so I don't think it is a new development. My observation is that the "business" role asked of the developer is more related to the size of the company and the company's primary business focus.
|
|
|
> I am prevented from downloading MP3 files at work, so I > apologize if my comment is out of context. > > What Loren observes has been true since I got into the > field around 1992, so I don't think it is a new > development. My observation is that the "business" role > asked of the developer is more related to the size of the > company and the company's primary business focus.
Someone should do a survey about whether people prefer podcasts to traditional interview transcripts. I hate podcasts.
Anyway, how would you say it is related to size and business focus?
I would say it mostly depends on the IT/development organization. Some organizations promote acquiring domain knowledge. Some emphasise only technical knowledge. Developers also tend to gravitate one way or the other.
Overall I would say the "industry" is far more concerned with technical skills, but our customers are far more balanced.
|
|
|
> Anyway, how would you say it is related to size and > business focus? > > I would say it mostly depends on the IT/development > organization. Some organizations promote acquiring domain > knowledge. Some emphasise only technical knowledge. > Developers also tend to gravitate one way or the other.
I agree that it is organization dependent. Let me use some examples to explain what I meant. A number of years ago I worked in the IT department for a hospital. We had precisely two developers, including myself, and a UNIX administrator. The IT department was small enough that, in order to work on their electronic patient chart system, I sat with the clinicians as they used our system and was able to see first hand how they use information we provided. It gave me an application domain knowledge that I don't believe a developer in a medical software company would have. Contrast this experience with my following job which was developing software for a financial company. The development staff was much larger - around 90 people including analysts. On one particularly large project, I was not allowed to talk with the user community. All knowledge of the business came through business analysts. I believe organizational size determines how much specialization can occur. At the hospital, I did analysis, coding, database administration, support, and project management. At the finance company, we had business analysts, DBA's, support staff, and project managers. The finance company simply had a larger staff, which allowed for specialization.
Referring back to my comment about a hypothetical developer in a medical software company versus me in a hospital IT shop. The hypothetical developer would probably have a much greater knowledge of traditional computer science topics, for instance algorithmic analysis or language design, than I would because I'm not being called on to know those areas: it was not what the hospital cared about. Where a software company benefits by having very technically skilled developers, my employer cared more about my having a greater understanding of how its people worked. (I'm not implying that developers in a medical software company don't acquire knowledge of the users' needs over time, but it takes longer than it does for someone working directly with a physician for instance.) > Overall I would say the "industry" is far more concerned > with technical skills, but our customers are far more > balanced.
The technology industry is definitely more concerned with technical skills. When developers work for non-technology industries, e.g. financial/medical/etc., there's less emphasis on technical skills and much more on understanding the organization and how the software is used.
I hope I've clarified what I meant.
|
|
|
I agree with Bill Pyne. Business has always preferred something more than a code monkey, but I guess the difference now is that we have these highly extensible tool frameworks like Eclipse.
|
|
|
> I agree with Bill Pyne. Business has always preferred > something more than a code monkey, but I guess the > difference now is that we have these highly extensible > tool frameworks like Eclipse.
I'd say it's more like 70% of business that prefers something more than a code monkey. I think there's a substantial minority that believe software development failures are caused by software developers trying to think rather than simply doing as their told.
IMHO you can see a lot of pandering to this perception in a lot of agile development literature.
|
|
|
> Someone should do a survey about whether people prefer > podcasts to traditional interview transcripts. I hate > podcasts. >
I second that...
|
|
|
> I am prevented from downloading MP3 files at work, so I > apologize if my comment is out of context. > > What Loren observes has been true since I got into the > field around 1992, so I don't think it is a new > development. My observation is that the "business" role > asked of the developer is more related to the size of the > company and the company's primary business focus.
I am not sure
|
|