<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: CA: In Pursuit of the Feature Rich Service Desk</title>
	<atom:link href="http://www.thevirtualcircle.com/2008/05/ca-in-pursuit-of-the-feature-rich-service-desk/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.thevirtualcircle.com/2008/05/ca-in-pursuit-of-the-feature-rich-service-desk/</link>
	<description>Just another WordPress site</description>
	<lastBuildDate>Wed, 28 Jul 2010 14:32:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=abc</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Robin Bloor</title>
		<link>http://www.thevirtualcircle.com/2008/05/ca-in-pursuit-of-the-feature-rich-service-desk/comment-page-1/#comment-258</link>
		<dc:creator>Robin Bloor</dc:creator>
		<pubDate>Sat, 17 May 2008 15:34:45 +0000</pubDate>
		<guid isPermaLink="false">http://havemacwillblog.com/2008/05/16/ca-in-pursuit-of-the-feature-rich-service-desk/#comment-258</guid>
		<description>Thanks for this feedback. A valuable and interesting contribution. IT splits between the professionals and the rest.</description>
		<content:encoded><![CDATA[<p>Thanks for this feedback. A valuable and interesting contribution. IT splits between the professionals and the rest.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen</title>
		<link>http://www.thevirtualcircle.com/2008/05/ca-in-pursuit-of-the-feature-rich-service-desk/comment-page-1/#comment-259</link>
		<dc:creator>Stephen</dc:creator>
		<pubDate>Sat, 17 May 2008 02:47:43 +0000</pubDate>
		<guid isPermaLink="false">http://havemacwillblog.com/2008/05/16/ca-in-pursuit-of-the-feature-rich-service-desk/#comment-259</guid>
		<description>I&#039;ve been able to make this happen.  I didn&#039;t call it a service desk.  Here&#039;s how it went down.

I&#039;d gotten a contract in 1999 with a brokerage firm.  They needed a C programmer. I did that, and they hired me.  Oddly, they then asked me to fix the intranet web server, which had a bunch of perl apps which totally overloaded the machine.  To make a long story short, i rewrote them in C - though i could have fixed them.  But in this process, i picked the tools that would make the job happen.  We had Apache on Solaris with Perl, with flat file databases. I picked C, with slightly better flat file databases. I used CVS for source control.  I designed apps that could work without modification in dev or prod, and multiple web servers on a single dev box could serve all developers - one each. I wrote documentation for procedures. I trained new developers, graphics designers, etc., in everything.  I was the Unix admin, the web server admin, the database designer and admin, i talked to the end users for app feedback, i was the developer, i was the source control admin.  Someone else did backups.

We had a help desk, but they just knew who to pass the problems to.  For my apps, there was monitoring, and mostly, i&#039;d fix things before any calls came in.  In fact, despite 2000 users who had to use these apps to get their work done, it would be two days before anyone called.  This appears true everywhere i&#039;ve been.

My system really worked.  When the help desk called me, it was an exciting challenge to be nailed right away.  It didn&#039;t hang out for hours or months.  And the key wasn&#039;t some BS corporate policy - it was a senior developer with competence and internal discipline, empowered to get the job done.  And, it was efficient.

In modern Java shops, there&#039;s Java, Eclipse, Javascript, HTML, JSPs, Flash, an RDBMS, Unix, some web server, and so on, and a whole team is needed to have any chance to have at least someone who knows enough about each part.  But instead of having such a team all in one spot, the modern corporate culture splits up the basic competence into a vast number of silos, with a ticket system for people to request services. So, if the permissions on a file are wrong, instead of issuing three commands and you&#039;re done in five minutes, some seven weeks goes by.  And everything has to be tested to the nth degree because if there&#039;s an error, it&#039;s 12 weeks to fix.  Basic competence is gone. Oh, and sometimes errors get introduced somehow.  Well maybe the Unix admin runs out of space and moves the data.  How do the apps find where it went? The Unix admin doesn&#039;t know, and worse, she doesn&#039;t know which developers (assuming they&#039;re still at the jobs) knows anything about the apps - or even which apps might care.

The really sad thing is that Fred Brooks said that this isn&#039;t the way to go about 20 years ago.  He was right about basically everything else. But the only way i&#039;ve been able to put together a surgical team is to be every team member at the start and grow the team from there.

My manager called me Clark, for some reason.  But they let me go, probably to find someone cheaper.  Good luck with that one.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been able to make this happen.  I didn&#8217;t call it a service desk.  Here&#8217;s how it went down.</p>
<p>I&#8217;d gotten a contract in 1999 with a brokerage firm.  They needed a C programmer. I did that, and they hired me.  Oddly, they then asked me to fix the intranet web server, which had a bunch of perl apps which totally overloaded the machine.  To make a long story short, i rewrote them in C &#8211; though i could have fixed them.  But in this process, i picked the tools that would make the job happen.  We had Apache on Solaris with Perl, with flat file databases. I picked C, with slightly better flat file databases. I used CVS for source control.  I designed apps that could work without modification in dev or prod, and multiple web servers on a single dev box could serve all developers &#8211; one each. I wrote documentation for procedures. I trained new developers, graphics designers, etc., in everything.  I was the Unix admin, the web server admin, the database designer and admin, i talked to the end users for app feedback, i was the developer, i was the source control admin.  Someone else did backups.</p>
<p>We had a help desk, but they just knew who to pass the problems to.  For my apps, there was monitoring, and mostly, i&#8217;d fix things before any calls came in.  In fact, despite 2000 users who had to use these apps to get their work done, it would be two days before anyone called.  This appears true everywhere i&#8217;ve been.</p>
<p>My system really worked.  When the help desk called me, it was an exciting challenge to be nailed right away.  It didn&#8217;t hang out for hours or months.  And the key wasn&#8217;t some BS corporate policy &#8211; it was a senior developer with competence and internal discipline, empowered to get the job done.  And, it was efficient.</p>
<p>In modern Java shops, there&#8217;s Java, Eclipse, Javascript, HTML, JSPs, Flash, an RDBMS, Unix, some web server, and so on, and a whole team is needed to have any chance to have at least someone who knows enough about each part.  But instead of having such a team all in one spot, the modern corporate culture splits up the basic competence into a vast number of silos, with a ticket system for people to request services. So, if the permissions on a file are wrong, instead of issuing three commands and you&#8217;re done in five minutes, some seven weeks goes by.  And everything has to be tested to the nth degree because if there&#8217;s an error, it&#8217;s 12 weeks to fix.  Basic competence is gone. Oh, and sometimes errors get introduced somehow.  Well maybe the Unix admin runs out of space and moves the data.  How do the apps find where it went? The Unix admin doesn&#8217;t know, and worse, she doesn&#8217;t know which developers (assuming they&#8217;re still at the jobs) knows anything about the apps &#8211; or even which apps might care.</p>
<p>The really sad thing is that Fred Brooks said that this isn&#8217;t the way to go about 20 years ago.  He was right about basically everything else. But the only way i&#8217;ve been able to put together a surgical team is to be every team member at the start and grow the team from there.</p>
<p>My manager called me Clark, for some reason.  But they let me go, probably to find someone cheaper.  Good luck with that one.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
