<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: What you&#8217;ll write tomorrow is not what you think today</title>
	<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/</link>
	<description>Nonlinearities of software development</description>
	<pubDate>Thu, 24 Jul 2008 15:06:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.1</generator>

	<item>
		<title>by: Imre Lumiste</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-147</link>
		<pubDate>Mon, 16 Oct 2006 12:42:01 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-147</guid>
					<description>Why should the internal backbone be public? The difference between public and private interface is huge in terms of flexibility, cost and need for documentation. Thus, making the API public still counts as a feature to me.</description>
		<content:encoded><![CDATA[<p>Why should the internal backbone be public? The difference between public and private interface is huge in terms of flexibility, cost and need for documentation. Thus, making the API public still counts as a feature to me.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Manuel Chromatic Mayflower</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-146</link>
		<pubDate>Mon, 16 Oct 2006 11:32:33 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-146</guid>
					<description>Public API cannot be regarded as &quot;any other feature&quot;. It's the backbone of your app and thus will always have at least one paying and highly participant customer - you yourself.</description>
		<content:encoded><![CDATA[<p>Public API cannot be regarded as &#8220;any other feature&#8221;. It&#8217;s the backbone of your app and thus will always have at least one paying and highly participant customer - you yourself.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Karel Kravik</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-115</link>
		<pubDate>Mon, 09 Oct 2006 17:00:46 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-115</guid>
					<description>I've long ago trying to say (see the previous posts): &quot;every feature you have means some other feature left out&quot;.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve long ago trying to say (see the previous posts): &#8220;every feature you have means some other feature left out&#8221;.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Imre Lumiste</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-113</link>
		<pubDate>Mon, 09 Oct 2006 14:51:26 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-113</guid>
					<description>Sigmar:

this article was not meant to be anything personal, although yes, it has been inspired by some recent conversations.

Manuel:

any development decision should be justified by some business need. Our customers have the option to vote for having a public API by requesting for it. For some reason, they haven't done it. Perhaps it's because they have their own software to deliver. Or perhaps they trust us to deliver working solutions. As long as they don't give us any requirements, how would we know what they need?

Designing, implementing, documenting, testing and maintaining a public API is a tremendous effort that requires development resources on expense of all the other features that our customers actually want.

So far, we have provided most API features that have been asked for; there are a couple of requests waiting in line exactly because there are other features that seem to be even more useful for our users.</description>
		<content:encoded><![CDATA[<p>Sigmar:</p>
<p>this article was not meant to be anything personal, although yes, it has been inspired by some recent conversations.</p>
<p>Manuel:</p>
<p>any development decision should be justified by some business need. Our customers have the option to vote for having a public API by requesting for it. For some reason, they haven&#8217;t done it. Perhaps it&#8217;s because they have their own software to deliver. Or perhaps they trust us to deliver working solutions. As long as they don&#8217;t give us any requirements, how would we know what they need?</p>
<p>Designing, implementing, documenting, testing and maintaining a public API is a tremendous effort that requires development resources on expense of all the other features that our customers actually want.</p>
<p>So far, we have provided most API features that have been asked for; there are a couple of requests waiting in line exactly because there are other features that seem to be even more useful for our users.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Manuel Chromatic Mayflower</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-112</link>
		<pubDate>Mon, 09 Oct 2006 13:29:57 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-112</guid>
					<description>Well, why don't you just label the public API as &quot;provisional&quot; and let your customers decide whether they want to depend on it today or not? If your heavily data-centric application can't bear a public API after two-three years of development, you're misguided anyways.</description>
		<content:encoded><![CDATA[<p>Well, why don&#8217;t you just label the public API as &#8220;provisional&#8221; and let your customers decide whether they want to depend on it today or not? If your heavily data-centric application can&#8217;t bear a public API after two-three years of development, you&#8217;re misguided anyways.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Sigmar</title>
		<link>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-111</link>
		<pubDate>Mon, 09 Oct 2006 12:58:49 +0000</pubDate>
		<guid>http://www.changelogic.com/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/#comment-111</guid>
					<description>I think that the motivation for this article here came from Villu and ME :D, because I am one of these guys who like to make something for everything. And Villu is also making suggestions to make something for everything. Ok, I understand this what Imre tries to tell here. So, programmer should just understand, what is he(or she) doing at the moment: just adding or improving functionality or developing a framework or building an architecture:), and if he doesnt really understand it, then it's boss's job to point on it:)</description>
		<content:encoded><![CDATA[<p>I think that the motivation for this article here came from Villu and ME <img src='http://www.changelogic.com/weblog/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> , because I am one of these guys who like to make something for everything. And Villu is also making suggestions to make something for everything. Ok, I understand this what Imre tries to tell here. So, programmer should just understand, what is he(or she) doing at the moment: just adding or improving functionality or developing a framework or building an architecture:), and if he doesnt really understand it, then it&#8217;s boss&#8217;s job to point on it:)
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
<div id='error'>
			<p class='wpdberror'><strong>WordPress database error:</strong> [Can't open file: 'wp_slim_stats.MYI' (errno: 145)]<br />
			<code>INSERT INTO wp_slim_stats ( `remote_ip`, `language`, `country`, `referer`, `domain`, `searchterms`, `resource`, `platform`, `browser`, `version`, `dt` ) VALUES ( "644300560", "en-us", "us", "", "", "", "/weblog/2006/10/03/what-youll-write-tomorrow-is-not-what-you-think-today/feed/", "-1", "34", "", "1216911977" )</code></p>
			</div>