<?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: The Spread-able System</title>
	<atom:link href="http://www.hackinghat.com/index.php/article/the-spread-able-system/feed" rel="self" type="application/rss+xml" />
	<link>http://www.hackinghat.com/index.php/article/the-spread-able-system</link>
	<description></description>
	<lastBuildDate>Tue, 20 Jul 2010 09:51:44 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Graham King</title>
		<link>http://www.hackinghat.com/index.php/article/the-spread-able-system/comment-page-1#comment-13680</link>
		<dc:creator>Graham King</dc:creator>
		<pubDate>Thu, 08 Jan 2009 04:06:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.hackinghat.com/index.php/article/the-spread-able-system#comment-13680</guid>
		<description>I wonder if putting the sheet online would solve many of the problems? Replace Excel with Google Docs (http://docs.google.com/) or Zoho Sheet (http://sheet.zoho.com/).

Google Docs has a revision history, real-time collaboration on a document (and chat whilst you edit), e-mail notifications, and of course no versioning / distribution problem.

There&#039;s no VBA, but there are Gadgets, written in Javascript.
And of course there&#039;s a real API with libraries in all major languages, so we&#039;re free of the Microsoft silo.

*Now* we&#039;re talking.</description>
		<content:encoded><![CDATA[<p>I wonder if putting the sheet online would solve many of the problems? Replace Excel with Google Docs (<a href="http://docs.google.com/" rel="nofollow">http://docs.google.com/</a>) or Zoho Sheet (<a href="http://sheet.zoho.com/" rel="nofollow">http://sheet.zoho.com/</a>).</p>
<p>Google Docs has a revision history, real-time collaboration on a document (and chat whilst you edit), e-mail notifications, and of course no versioning / distribution problem.</p>
<p>There&#8217;s no VBA, but there are Gadgets, written in Javascript.<br />
And of course there&#8217;s a real API with libraries in all major languages, so we&#8217;re free of the Microsoft silo.</p>
<p>*Now* we&#8217;re talking.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Moore</title>
		<link>http://www.hackinghat.com/index.php/article/the-spread-able-system/comment-page-1#comment-13626</link>
		<dc:creator>Simon Moore</dc:creator>
		<pubDate>Wed, 07 Jan 2009 09:46:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.hackinghat.com/index.php/article/the-spread-able-system#comment-13626</guid>
		<description>Hi there.

All valid points and well made. FYI I come at this from a user&#039;s point of view rather than a developer&#039;s.

Out of the pro&#039;s that you mention regarding spreadsheets, the utility one is by far the dominant feature. A piece of paper is also simple and portable (and has utility too, I guess). In particular, in the business environments which I have experienced, the ability to quickly knock something together to solve a problem is essential. In developer terms, I guess you would call this rapid prototyping. Consider a business where, for each ten client requests, only one gets executed. Then to value those requests, you are not going to build every single one into a system. You will do a quick and dirty on a spreadsheet; if the request is executed then only then will you consider putting it into a fully-fledged system.

Re. the cons, I also agree that by far the biggest (and probably only important) one is the inability to track changes. This explicity means that there is no audit trail and so any concept of process control disappears.

But I would add another con too - that of lack of scaleability (sp?). We have a simple problem, so we build a simple spreadsheet. Then we add a few tweaks, expand a few tables, add a few scenarios, and before long we have a monster. Spreadsheets are NOT scaleable. They are good for simple problems, but beyond a certain size thet become impractical and unsupportable.

So I think we need two things. The first, and hardest, is a spreadsheet version of SourceSafe or Subversion. This would allow changes to be tracked, an audit trail to be built, etc. I assume this is nigh-on impossible as no-one has done it so far - I leave that to the more technically minded to decide on. But I would have thought any product like this would have sold like hot cakes.

The second is the ability to take a spreadsheet and use that to develop a system. Some businesses let users develop their systems on spreadsheets, and then take them and use the spreadsheets as the requirements specification. There is a package out there (I can&#039;t remember the name but will try and dig it out) which turns spreadsheets into C++ modules. Hence, after a spreadsheet reaches a certain size, it can be turned into a &quot;real&quot; system (whatever that means).

Re. your comment on narrowing the gap. Has anyone looked at a finance system called Front Arena from Sungard? It is basically set up to work similarly to a spreadsheet. But it proves quite hard to sell. Client: &quot;Tell me, what can your system do?&quot; Sungard: &quot;Anything you want it to.&quot; And then the client buys it and it doesn&#039;t do anything until the client has spent ages telling it what to do... it&#039;s very flexibility is its Achilles heel.

[Aside: a good interview question for salespeople is &quot;tell me what a spreadsheet can do.&quot;]</description>
		<content:encoded><![CDATA[<p>Hi there.</p>
<p>All valid points and well made. FYI I come at this from a user&#8217;s point of view rather than a developer&#8217;s.</p>
<p>Out of the pro&#8217;s that you mention regarding spreadsheets, the utility one is by far the dominant feature. A piece of paper is also simple and portable (and has utility too, I guess). In particular, in the business environments which I have experienced, the ability to quickly knock something together to solve a problem is essential. In developer terms, I guess you would call this rapid prototyping. Consider a business where, for each ten client requests, only one gets executed. Then to value those requests, you are not going to build every single one into a system. You will do a quick and dirty on a spreadsheet; if the request is executed then only then will you consider putting it into a fully-fledged system.</p>
<p>Re. the cons, I also agree that by far the biggest (and probably only important) one is the inability to track changes. This explicity means that there is no audit trail and so any concept of process control disappears.</p>
<p>But I would add another con too &#8211; that of lack of scaleability (sp?). We have a simple problem, so we build a simple spreadsheet. Then we add a few tweaks, expand a few tables, add a few scenarios, and before long we have a monster. Spreadsheets are NOT scaleable. They are good for simple problems, but beyond a certain size thet become impractical and unsupportable.</p>
<p>So I think we need two things. The first, and hardest, is a spreadsheet version of SourceSafe or Subversion. This would allow changes to be tracked, an audit trail to be built, etc. I assume this is nigh-on impossible as no-one has done it so far &#8211; I leave that to the more technically minded to decide on. But I would have thought any product like this would have sold like hot cakes.</p>
<p>The second is the ability to take a spreadsheet and use that to develop a system. Some businesses let users develop their systems on spreadsheets, and then take them and use the spreadsheets as the requirements specification. There is a package out there (I can&#8217;t remember the name but will try and dig it out) which turns spreadsheets into C++ modules. Hence, after a spreadsheet reaches a certain size, it can be turned into a &#8220;real&#8221; system (whatever that means).</p>
<p>Re. your comment on narrowing the gap. Has anyone looked at a finance system called Front Arena from Sungard? It is basically set up to work similarly to a spreadsheet. But it proves quite hard to sell. Client: &#8220;Tell me, what can your system do?&#8221; Sungard: &#8220;Anything you want it to.&#8221; And then the client buys it and it doesn&#8217;t do anything until the client has spent ages telling it what to do&#8230; it&#8217;s very flexibility is its Achilles heel.</p>
<p>[Aside: a good interview question for salespeople is "tell me what a spreadsheet can do."]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
