Comments on: Software Design, In Two Sentences http://www.codesimplicity.com/post/software-design-in-two-sentence/ Tue, 27 Dec 2011 03:40:15 -0600 http://wordpress.org/?v=2.8.6 hourly 1 By: Max Kanat-Alexander http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-2032 Max Kanat-Alexander Fri, 05 Nov 2010 07:42:47 +0000 http://www.codesimplicity.com/?p=495#comment-2032 Yeah, I actually really thought about your comment a lot, and I think you're right. A more mathematically accurate statement would be something like: The Effort of Maintenance is a function of the complexity of the system. But I'm concerned that some people wouldn't really know what "is a function of" means. Yeah, I actually really thought about your comment a lot, and I think you’re right. A more mathematically accurate statement would be something like:

The Effort of Maintenance is a function of the complexity of the system.

But I’m concerned that some people wouldn’t really know what “is a function of” means.

]]> By: Harald Wellmann http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-2029 Harald Wellmann Wed, 27 Oct 2010 15:36:44 +0000 http://www.codesimplicity.com/?p=495#comment-2029 Assuming the number of maintenance issues in a system is proportional to its size, you also need to consider the extra time it takes to isolate and fix a problem in a larger system. That's why I believe the relation between maintenance effort and system size is not linear: In terms of complexity analysis, your second statement amounts to m = O(c) I would even claim that m = O(c log c) or m = O(c^2) Assuming the number of maintenance issues in a system is proportional to its size, you also need to consider the extra time it takes to isolate and fix a problem in a larger system.

That’s why I believe the relation between maintenance effort and system size is not linear:

In terms of complexity analysis, your second statement amounts to

m = O(c)

I would even claim that

m = O(c log c)

or

m = O(c^2)

]]> By: Todd A » Software Design in Two Sentences http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-2018 Todd A » Software Design in Two Sentences Thu, 15 Jul 2010 18:41:04 +0000 http://www.codesimplicity.com/?p=495#comment-2018 [...] This is what I argue all the time in web design though I’ve never said it as eloquently as Code Simplicity: 1. It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of [...] [...] This is what I argue all the time in web design though I’ve never said it as eloquently as Code Simplicity: 1. It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of [...]

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-2010 Max Kanat-Alexander Sat, 12 Jun 2010 20:36:27 +0000 http://www.codesimplicity.com/?p=495#comment-2010 Hmm. Okay, here's a few simple examples: We know that complexity leads to more effort of maintenance. What leads to complexity? Well, one thing that we can show leads to complexity is tight coupling of system components. So we can evolve a principle of loose coupling simply by looking for methods of reducing complexity. We want to reduce the effort of maintenance. So, we'd spend a bit of time observing what takes up our maintenance time. Fixing bugs certainly takes up quite a bit of that time. So wouldn't it be great if we could eliminate bug maintenance by catching them before they exist? With a bit of experimentation, we would probably evolve the the idea of automated testing. It's even simpler if you trace the lower-level principle back to these higher-level simplicities. It works for pretty much every software development principle, except for HCI principles, which I would consider a separate area. -Max Hmm. Okay, here’s a few simple examples:

We know that complexity leads to more effort of maintenance. What leads to complexity? Well, one thing that we can show leads to complexity is tight coupling of system components. So we can evolve a principle of loose coupling simply by looking for methods of reducing complexity.

We want to reduce the effort of maintenance. So, we’d spend a bit of time observing what takes up our maintenance time. Fixing bugs certainly takes up quite a bit of that time. So wouldn’t it be great if we could eliminate bug maintenance by catching them before they exist? With a bit of experimentation, we would probably evolve the the idea of automated testing.

It’s even simpler if you trace the lower-level principle back to these higher-level simplicities.

It works for pretty much every software development principle, except for HCI principles, which I would consider a separate area.

-Max

]]> By: Ape http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-1999 Ape Sat, 12 Jun 2010 10:43:47 +0000 http://www.codesimplicity.com/?p=495#comment-1999 I would like to see some examples of how you could evolve the rest of the principles. It would be interesting to observe this thought process and reasoning patterns involved. I would like to see some examples of how you could evolve the rest of the principles. It would be interesting to observe this thought process and reasoning patterns involved.

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-1957 Max Kanat-Alexander Thu, 20 May 2010 23:12:34 +0000 http://www.codesimplicity.com/?p=495#comment-1957 Well, I don't really buy into any particular existing software methodologies. So if somebody wants to say "Oh, this sounds a bit like some XP principle, and could work with it this way," and that <em>helps somebody</em>, that's great. But if the purpose is just to align the ideas because XP exists and somebody thinks that everything should fit with XP, then I don't think that's so great. Usually the folks who want to fit everything into their particular software methodology have something to gain personally--for example, they're consultants for that methodology, or they wrote a book about it and want to sell more books. Not that there's anything wrong with selling books or being a consultant. But there is something wrong with forwarding a set of ideas solely because one profits from them. -Max Well, I don’t really buy into any particular existing software methodologies. So if somebody wants to say “Oh, this sounds a bit like some XP principle, and could work with it this way,” and that helps somebody, that’s great. But if the purpose is just to align the ideas because XP exists and somebody thinks that everything should fit with XP, then I don’t think that’s so great. Usually the folks who want to fit everything into their particular software methodology have something to gain personally–for example, they’re consultants for that methodology, or they wrote a book about it and want to sell more books. Not that there’s anything wrong with selling books or being a consultant. But there is something wrong with forwarding a set of ideas solely because one profits from them.

-Max

]]> By: Wanderson Santos http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-1942 Wanderson Santos Tue, 18 May 2010 13:39:38 +0000 http://www.codesimplicity.com/?p=495#comment-1942 I fully agree, but can we align this to agile principles like "Simple Design" in XP? I fully agree, but can we align this to agile principles like “Simple Design” in XP?

]]> By: Mark Castillo http://www.codesimplicity.com/post/software-design-in-two-sentence/comment-page-1/#comment-1651 Mark Castillo Thu, 13 May 2010 21:01:01 +0000 http://www.codesimplicity.com/?p=495#comment-1651 hehe... I'm still looking for the principle of Zero Effort for implementation AND maintenance. Maybe basic principle could be had here ... "zero effort is unattainable". hehe… I’m still looking for the principle of Zero Effort for implementation AND maintenance. Maybe basic principle could be had here … “zero effort is unattainable”.

]]>