<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Thinking inside a bigger box - Latest Comments in Myopic Software Development</title><link>http://thinkinginsideabiggerbox.disqus.com/</link><description></description><language>en</language><lastBuildDate>Sun, 16 Jul 2006 14:54:40 -0000</lastBuildDate><item><title>Re: Myopic Software Development</title><link>http://www.brodwall.com/johannes/blog/2006/07/16/myopic-software-development/#comment-1796596</link><description>Hi Sergio,&lt;br&gt;Thank you for you comment&lt;br&gt;&lt;br&gt;I agree. "Elegant" is not a good word for what I wanted to express. Maybe "perfect" would be better. When it comes to creating reusable solutions, I try and avoid creating reusable solutions "up front", and instead evolve them in a more myopic fashion.&lt;br&gt;&lt;br&gt;When it comes to domain models, I think our experience is different. I create a skeletal domain model early, then I usually let the rest evolve as I need it. I think both approaches can be valid. Of course, before putting code into production, I like to check what freedom of motion I have left with the database schema.&lt;br&gt;&lt;br&gt;&lt;br&gt;~Johannes</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Johannes Brodwall</dc:creator><pubDate>Sun, 16 Jul 2006 14:54:40 -0000</pubDate></item><item><title>Re: Myopic Software Development</title><link>http://www.brodwall.com/johannes/blog/2006/07/16/myopic-software-development/#comment-1796595</link><description>Hi Johannes,&lt;br&gt;&lt;br&gt;I agree with you in many points: yes, we surely tend to look too much toward what will happen in the future.&lt;br&gt;I just disagree when you say that instead of creating elegant solutions we should keep everything simple; yes, everything should be kept as simple as possible, but this doesn't exclude good, elegant and reusable solutions: there should be some kind of middle ground.&lt;br&gt;&lt;br&gt;Moreover, I think that up front development and testing of the domain model, in isolation with other layers, helps in focusing to current, real, requirements, because coding the domain model is all about solving your real problems.&lt;br&gt;&lt;br&gt;My 2 euro cents.&lt;br&gt;&lt;br&gt;Cheers,&lt;br&gt;&lt;br&gt;Sergio B.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sergio Bossa</dc:creator><pubDate>Sun, 16 Jul 2006 14:44:37 -0000</pubDate></item></channel></rss>