<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Christian Rørdam</title><link>http://disqus.com/people/6b4f04e2e9a287e7cded09e810bc373e/</link><description></description><language>en</language><lastBuildDate>Fri, 03 Apr 2009 09:01:10 -0000</lastBuildDate><item><title>Re: On Architecture: The dubious joy of system architecture revision</title><link>http://thinkinginsideabiggerbox.disqus.com/on_architecture_the_dubious_joy_of_system_architecture_revision/#comment-1797691</link><description>I'm happy to see that there are people who are concerned about the maintainability of systems. It seems like most people don't care, or they don't have the time right now, or they believe that their code is as easy to understand for other developers as it is for them.&lt;br&gt;&lt;br&gt;I very rarely experience that developers take this aspect into account when they produce something. Maybe not so strange though, as it takes a lot more effort and time (and experience and perhaps some talent) than just making it work. As long as you are under some time pressure, and your manager doesn't ask for it (and probably nobody else either), why should you bother?&lt;br&gt;&lt;br&gt;I think the only way to prevent systems from becoming a mess is to have clear requirements for maintainability, so that it is clear that the system is not finished until these requirements are met.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Mon, 19 Feb 2007 06:29:50 -0000</pubDate></item><item><title>Re: The Waterfall Process Distilled</title><link>http://thinkinginsideabiggerbox.disqus.com/the_waterfall_process_distilled/#comment-1797700</link><description>This sounds very familiar, all though all projects I have attended were supposed to be iterative from the start...</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Mon, 19 Feb 2007 11:39:10 -0000</pubDate></item><item><title>Re: On Architecture: The dubious joy of system architecture revision</title><link>http://thinkinginsideabiggerbox.disqus.com/on_architecture_the_dubious_joy_of_system_architecture_revision/#comment-1797693</link><description>You are pointing out the two main problems here. I'll respond to the last one first: the customer doesn't ask for it and is in a hurry. However, the customer really needs it, even though they are not aware of this fact. I have seen several reports estimating that "two-thirds of a software system's lifetime cost involves maintenance" (quote taken from &lt;a href="http://en.wikipedia.org/wiki/Software_maintenance" rel="nofollow"&gt;http://en.wikipedia.org/wiki/Software_maintenance&lt;/a&gt;). So it is really in the interest of the customer that this job is as easy as possible, since it is usually the customer who has to pay for it.&lt;br&gt;&lt;br&gt;The company creating the software, however, usually doesn't have much interest in this, because they will mostly get paid in full for any job they do after delivery, and the maintainability of their creation does not effect their chances of getting a contract for the maintenance. &lt;br&gt;&lt;br&gt;So the only victim here is the customer, who will have to pay more for changes (well, and the poor people who are assigned to the maintenance job, and they are quite often not those who developed it).&lt;br&gt;&lt;br&gt;The second problem is the quantification of maintainability. That is not easy to do, but we all clearly see the difference between code that is easy to change, and code that we don't dear to touch. This tells me that it should be possible to test this somehow.&lt;br&gt;&lt;br&gt;My main point, however, is this:&lt;br&gt;the customer must demand and control that the system they buy is reasonably maintainable. Nobody else will do it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Tue, 20 Feb 2007 13:22:55 -0000</pubDate></item><item><title>Re: On Architecture: The dubious joy of system architecture revision</title><link>http://thinkinginsideabiggerbox.disqus.com/on_architecture_the_dubious_joy_of_system_architecture_revision/#comment-1797695</link><description>The customers must become aware of their need, and that will probably not happen tomorrow. However, I wouldn't be surprised if a customer signing a contract for a tailor made system tomorrow included some sentences about automated tests. I guess it's a matter of how much attention things get.&lt;br&gt;&lt;br&gt;Automated tests improve maintainability, so if customers start demanding that, then one piece is in place. For this part, we also have good measures.&lt;br&gt;&lt;br&gt;I think customers are willing to pay for it if they understand that it is good economy. The customer will probably need to hire people to check for them, just like they often hire people to check the architecture, the project management and more.&lt;br&gt;&lt;br&gt;Are we able to reliably deliver it? I don't know. Are we able to reliably deliver good architecture? There are at least some best practices one can state (like the negation of these tips: &lt;a href="http://thc.org/root/phun/unmaintain.html" rel="nofollow"&gt;http://thc.org/root/phun/unmaintain.html&lt;/a&gt;).&lt;br&gt;&lt;br&gt;Even though it is difficult to standardize tests for this, one can try to make some changes and see how difficult it is. If it is hard, you will see what makes it hard, and hopefully whether it really needs to be like that.&lt;br&gt;&lt;br&gt;Are you being defeatist? I agree that the road is really long, but I don't think it is endless.&lt;br&gt;&lt;br&gt;Do you?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Wed, 21 Feb 2007 14:54:30 -0000</pubDate></item><item><title>Re: Spring - You've Failed Me</title><link>http://thinkinginsideabiggerbox.disqus.com/spring_youve_failed_me/#comment-1798014</link><description>I totally agree with you, Johannes and Bjørn. There is absolutely no reason why you should program in XML if you can do it in Java. I think there is a general misunderstanding among many people that separating the wiring code (or the business rules for that matter) from the rest of the code means that one should use a different format. Rubbish! Just put it in a separate place.&lt;br&gt;&lt;br&gt;I haven't tried the annotation style, but I don't like the idea, as it is intrusive. I think the best thing is to have a separate module/package with Java code that wires up the other modules.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Thu, 17 May 2007 06:37:25 -0000</pubDate></item><item><title>Re: Agile architecture reduces the need for documentation</title><link>http://thinkinginsideabiggerbox.disqus.com/agile_architecture_reduces_the_need_for_documentation/#comment-1798819</link><description>Ah, I love the smell of WebSphere criticism in the morning.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Mon, 05 Nov 2007 06:32:34 -0000</pubDate></item><item><title>Re: Testing: Avoid setUp and tearDown</title><link>http://thinkinginsideabiggerbox.disqus.com/testing_avoid_setup_and_teardown/#comment-1799205</link><description>Agreed! I think it is important that a test method can be read as a sequence of steps, but the steps can be reusable methods. So I do extract the gory details of actually performing the step, but I usually don't extract a subsequence of steps as a new method. And of course, I try to give the methods as good names as possible, as always.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Thu, 03 Jul 2008 04:35:51 -0000</pubDate></item><item><title>Re: Keep the build clean</title><link>http://thinkinginsideabiggerbox.disqus.com/keep_the_build_clean/#comment-4932800</link><description>Yes! I am sure you will benefit from this.&lt;br&gt;&lt;br&gt;I hardly ever get in from the start, so I have to fix a warning here and there and it seems like a Sisyphean task, and if I suggest to others that they should do the same, they agree it's a good idea, but then they don't do it, and who can blame them, as they have their designated tasks that their boss wants to see finished. And as a task, it will always be prioritized below most other things and therefore never be done.&lt;br&gt;&lt;br&gt;So I think the only way to ever get a clean build is to keep it clean from the start.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Tue, 06 Jan 2009 09:17:23 -0000</pubDate></item><item><title>Re: Keep the build clean</title><link>http://thinkinginsideabiggerbox.disqus.com/keep_the_build_clean/#comment-4990579</link><description>Nice view!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Thu, 08 Jan 2009 12:35:48 -0000</pubDate></item><item><title>Re: &amp;#8230; but please do repeat me</title><link>http://thinkinginsideabiggerbox.disqus.com/8230_but_please_do_repeat_me/#comment-6326448</link><description>An important discussion, and I think you summarize the dilemma quite well.&lt;br&gt;&lt;br&gt;May I add a point:&lt;br&gt;Sometimes you need a new module that starts out identical to some&lt;br&gt;other module, but actually it is totally independent of the other&lt;br&gt;module and will most likely divert more and more from it. In that case&lt;br&gt;I think you will be better off just copying the whole thing and let it&lt;br&gt;live its own life. I think.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Tue, 17 Feb 2009 04:30:03 -0000</pubDate></item><item><title>Re: Planning by value</title><link>http://thinkinginsideabiggerbox.disqus.com/planning_by_value/#comment-7786959</link><description>Regarding the German language home work: If the questions really cover all you need to know about that chapter, then I don't see any problems with this approach. I real life, however, the end-of-the-chapter questions only cover some of it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Fri, 03 Apr 2009 09:01:10 -0000</pubDate></item></channel></rss>