<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Software is too expensive to build cheaply... &#187; design</title>
	<atom:link href="http://twasink.net/blog/tags/design/feed/" rel="self" type="application/rss+xml" />
	<link>http://twasink.net/blog</link>
	<description>Robert's Rambling Ruminations Regarding Reality</description>
	<lastBuildDate>Fri, 16 Jul 2010 06:57:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Interfaces with EJB3</title>
		<link>http://twasink.net/blog/2007/01/interfaces-with-ejb3/</link>
		<comments>http://twasink.net/blog/2007/01/interfaces-with-ejb3/#comments</comments>
		<pubDate>Sat, 27 Jan 2007 21:54:49 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[ejb]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>
		<category><![CDATA[wotif]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=204</guid>
		<description><![CDATA[Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.
One of the things I noticed was that EJB3 gives you a lot of choices for [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2007/01/interfaces-with-ejb3/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>JBR&#8217;s Postulate 1</title>
		<link>http://twasink.net/blog/2005/09/jbrs-postulate-1/</link>
		<comments>http://twasink.net/blog/2005/09/jbrs-postulate-1/#comments</comments>
		<pubDate>Fri, 02 Sep 2005 07:22:01 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=162</guid>
		<description><![CDATA[From the JUnit mailing list, courtesy of J.B &#34;JUnit Recipies&#34; Rainsberger
JBR&#8217;s postulate 1. For every testable design that requires exposing elements &#8220;just for testing&#8221;, there exists an equivalent testable design that does not require exposing elements &#8220;just for testing&#8221;.
]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/09/jbrs-postulate-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Peering into the crystal ball: BDUF vs emergent design</title>
		<link>http://twasink.net/blog/2005/09/peering-into-the-crystal-ball-bduf-vs-emergent-design/</link>
		<comments>http://twasink.net/blog/2005/09/peering-into-the-crystal-ball-bduf-vs-emergent-design/#comments</comments>
		<pubDate>Thu, 01 Sep 2005 18:17:06 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[bduf]]></category>
		<category><![CDATA[design]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=159</guid>
		<description><![CDATA[There&#8217;s always a lot of debate in the various agile groups about what BDUF is, why you should avoid it, when you should avoid it, and why is it bad (or good) for you. I just thought I&#8217;d outline my own opinions here.

BDUF, to me, is an attempt to peer into the future. It&#8217;s about [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/09/peering-into-the-crystal-ball-bduf-vs-emergent-design/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>It&#8217;s a bird, it&#8217;s a plane&#8230; it&#8217;s a super call?</title>
		<link>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/</link>
		<comments>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/#comments</comments>
		<pubDate>Fri, 12 Aug 2005 07:27:06 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[junit]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=156</guid>
		<description><![CDATA[Martin Fowler wrote about the Call Super smell. This occurs when you are allowed to override a method in a parent class, but you must (as opposed to can) call the parent implementation in your method.

As Martin says, this is a code smell. Why? Because it&#8217;s easy to forget, and if you forget it, you [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/08/its-a-bird-its-a-plane-its-a-super-call/feed/</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>Your brain on design pattens</title>
		<link>http://twasink.net/blog/2005/08/your-brain-on-design-pattens/</link>
		<comments>http://twasink.net/blog/2005/08/your-brain-on-design-pattens/#comments</comments>
		<pubDate>Thu, 11 Aug 2005 22:26:12 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Book Reviews]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[learning]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=155</guid>
		<description><![CDATA[
Picked up my copy of Head First Design Patterns today (I&#8217;d ordered it in a couple of weeks ago). So far I&#8217;m loving it.

I&#8217;d been eyeing this book off for a while since reading the sample chapter for this and for Head First Java The presentation style looks like it should be childish and silly, [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/08/your-brain-on-design-pattens/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Testing pattern: don&#8217;t test too much at once</title>
		<link>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/</link>
		<comments>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/#comments</comments>
		<pubDate>Thu, 28 Jul 2005 22:59:11 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Agile Development]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[economics]]></category>
		<category><![CDATA[patterns]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=152</guid>
		<description><![CDATA[This has been said before, I know, but it&#8217;s worth re-iterating: a test should test one thing, and one thing only.
First, some scope definition. Using Kent Beck&#8217;s terminology, I&#8217;m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/07/testing-pattern-dont-test-too-much-at-once/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Interfaces are interesting&#8230;</title>
		<link>http://twasink.net/blog/2005/06/interfaces-are-interesting/</link>
		<comments>http://twasink.net/blog/2005/06/interfaces-are-interesting/#comments</comments>
		<pubDate>Thu, 09 Jun 2005 22:17:54 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[patterns]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=148</guid>
		<description><![CDATA[Cedric&#8217;s got an interesting post on obtaining extensibility via interfaces As usual, he makes a lot of very good points, and (again, as usual when I link to Cedric&#8217;s posts), there are a couple that I think could be elaborated on.

I&#8217;d suggest you read Cedric&#8217;s post to get the main gist, but here&#8217;s a quick [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/06/interfaces-are-interesting/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Your code sucks because&#8230;</title>
		<link>http://twasink.net/blog/2005/05/your-code-sucks-because/</link>
		<comments>http://twasink.net/blog/2005/05/your-code-sucks-because/#comments</comments>
		<pubDate>Wed, 11 May 2005 22:48:16 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[anti-pattern]]></category>
		<category><![CDATA[coding standards]]></category>
		<category><![CDATA[design]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=137</guid>
		<description><![CDATA[I rediscovered this article while doing some research. It gives an extensive list of reasons why your code sucks.
]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/05/your-code-sucks-because/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Granularity of types</title>
		<link>http://twasink.net/blog/2005/04/granularity-of-types/</link>
		<comments>http://twasink.net/blog/2005/04/granularity-of-types/#comments</comments>
		<pubDate>Wed, 13 Apr 2005 09:55:52 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=131</guid>
		<description><![CDATA[Elizabeth Keogh has been writing a couple of articles on naming of interfaces. In the process, she&#8217;s highlighted a more important issue: granularity of types.

IMHO opinion, base types (those that don&#8217;t inherit from other types) should be fairly fine grained. You can always aggregate types together to get coarse-grained types, but you can&#8217;t go back [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/04/granularity-of-types/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Differences cause problems</title>
		<link>http://twasink.net/blog/2005/03/differences-cause-problems/</link>
		<comments>http://twasink.net/blog/2005/03/differences-cause-problems/#comments</comments>
		<pubDate>Mon, 07 Mar 2005 16:45:07 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://twasink.net/wp/?p=115</guid>
		<description><![CDATA[This is obvious, but differences between environments cause problems. You can expect bugs to cluster around them.

Case in point: on my current project, we use a hand-maintained schema for production (and manual testing), but our unit tests go against one that is generated from the Hibernate schema. Naturally, we are seeing bugs related to differences [...]]]></description>
		<wfw:commentRss>http://twasink.net/blog/2005/03/differences-cause-problems/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
