Comments on: Design From The Start http://www.codesimplicity.com/post/design-from-the-start/ 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/design-from-the-start/comment-page-1/#comment-1072 Max Kanat-Alexander Tue, 28 Jul 2009 02:43:03 +0000 http://www.codesimplicity.com/?p=43#comment-1072 Thanks! :-) -Max Thanks! :-)

-Max

]]> By: Bob http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-1071 Bob Tue, 28 Jul 2009 01:49:22 +0000 http://www.codesimplicity.com/?p=43#comment-1071 nice! nice!

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-487 Max Kanat-Alexander Sun, 17 Aug 2008 07:42:57 +0000 http://www.codesimplicity.com/?p=43#comment-487 He's right, but he's wrong about <em>why</em> he's right and he's wrong in some of the things he says. You <em>should</em> expect the project to get large. You should <em>not</em> <a href="/archives/12" rel="nofollow">overengineer</a>. And you should <em>not</em> <a href="/archives/6" rel="nofollow">design too far into the future</a> (which is the point he's actually making). Also note that he's making a point about open-source software--about what makes people want to contribute. -Max He’s right, but he’s wrong about why he’s right and he’s wrong in some of the things he says. You should expect the project to get large. You should not overengineer. And you should not design too far into the future (which is the point he’s actually making).

Also note that he’s making a point about open-source software–about what makes people want to contribute.

-Max

]]> By: fulano http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-482 fulano Sat, 16 Aug 2008 18:42:29 +0000 http://www.codesimplicity.com/?p=43#comment-482 "Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way _useful_ first, and then others will say "hey, that _almost_ works for me", and they'll get involved in the project." - Torvalds “Nobody should start to undertake a large project. You start with a small _trivial_ project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way _useful_ first, and then others will say “hey, that _almost_ works for me”, and they’ll get involved in the project.” – Torvalds

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-480 Max Kanat-Alexander Sat, 16 Aug 2008 01:39:26 +0000 http://www.codesimplicity.com/?p=43#comment-480 Hey, you're welcome! :-) -Max Hey, you’re welcome! :-)

-Max

]]> By: Casper Bang http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-479 Casper Bang Fri, 15 Aug 2008 23:51:35 +0000 http://www.codesimplicity.com/?p=43#comment-479 I just finished reading "Practical API design - Confessions of a Java Framework Architect" by Jaroslav Tulach (original author of NetBeans). And in it he describes similar experiences to yours. However, he focuses a lot (too much) on backwards compatibility and comes with statements such as "simplicity and elegance is not the goal at all". That made me a little depressed so, intentional or not, thanks for pulling a little in the other direction with this blog! ;) I just finished reading “Practical API design – Confessions of a Java Framework Architect” by Jaroslav Tulach (original author of NetBeans). And in it he describes similar experiences to yours. However, he focuses a lot (too much) on backwards compatibility and comes with statements such as “simplicity and elegance is not the goal at all”. That made me a little depressed so, intentional or not, thanks for pulling a little in the other direction with this blog! ;)

]]> By: Max Kanat-Alexander http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-478 Max Kanat-Alexander Fri, 15 Aug 2008 22:18:44 +0000 http://www.codesimplicity.com/?p=43#comment-478 Hey Casper! I have seen the same thing happen. At least caring about design, and noticing that patches and workarounds are moving away from it, that's commendable. Now, I too have seen situations where people said that doing things the right way wasn't practically or economically feasible. But somehow a re-write (more effort later) is? In commercial environments (and a little bit in open-source environments), there's also a big push to "stay competitive." That is, to make sure that you have the same or better features than your competitors. Sadly, that's all too often just measured by the size of the feature list, and not by the quality of each individual feature in the product. Shipping a little later than your competitor with a better product isn't actually harmful to business. Shipping <em>years</em> later (witness IE7 and Vista) is, but it's not usually gold-plating that causes years of lateness. It's re-writing that does. As far as being called a gold-plating perfectionist, people who say that are probably the types who can't see beyond lunch. They're also often the types who don't want to stand away from the computer for even a few minutes to think about a design. That's one reason why design shouldn't be a democracy. Design should really be a dictatorship, and anybody who doesn't understand it (and would rather do things the wrong way, often out of ignorance) should be forced to implement it. And actually, usually what happens is when you force them, after about two years they start to understand why you did it and what's important about it, at least a tiny bit. There have been times with Bugzilla that I've compromised, I will say that. But it was because all our contributors are volunteers, and I had to make the decision: "If I tell them to fix this, they won't, and then we won't have the feature at all. If I let it in as-is, we'll have the feature but it'll suck." But honestly, the more I do that, the less I think it was a good idea. I've had so much trouble caused by allowing those things--particularly bugs and incomplete features that users complain about--that I'm really disinclined to ever do it again. -Max Hey Casper! I have seen the same thing happen. At least caring about design, and noticing that patches and workarounds are moving away from it, that’s commendable.

Now, I too have seen situations where people said that doing things the right way wasn’t practically or economically feasible. But somehow a re-write (more effort later) is?

In commercial environments (and a little bit in open-source environments), there’s also a big push to “stay competitive.” That is, to make sure that you have the same or better features than your competitors. Sadly, that’s all too often just measured by the size of the feature list, and not by the quality of each individual feature in the product. Shipping a little later than your competitor with a better product isn’t actually harmful to business. Shipping years later (witness IE7 and Vista) is, but it’s not usually gold-plating that causes years of lateness. It’s re-writing that does.

As far as being called a gold-plating perfectionist, people who say that are probably the types who can’t see beyond lunch. They’re also often the types who don’t want to stand away from the computer for even a few minutes to think about a design. That’s one reason why design shouldn’t be a democracy. Design should really be a dictatorship, and anybody who doesn’t understand it (and would rather do things the wrong way, often out of ignorance) should be forced to implement it. And actually, usually what happens is when you force them, after about two years they start to understand why you did it and what’s important about it, at least a tiny bit.

There have been times with Bugzilla that I’ve compromised, I will say that. But it was because all our contributors are volunteers, and I had to make the decision: “If I tell them to fix this, they won’t, and then we won’t have the feature at all. If I let it in as-is, we’ll have the feature but it’ll suck.” But honestly, the more I do that, the less I think it was a good idea. I’ve had so much trouble caused by allowing those things–particularly bugs and incomplete features that users complain about–that I’m really disinclined to ever do it again.

-Max

]]> By: Casper Bang http://www.codesimplicity.com/post/design-from-the-start/comment-page-1/#comment-477 Casper Bang Fri, 15 Aug 2008 19:13:03 +0000 http://www.codesimplicity.com/?p=43#comment-477 Max, interesting post. No matter how much design you do, users will always sneak in requests and features which ends up as patches and workarounds. Eventually you start to see more and more regressions and a major refactoring or perhaps even redesign is called for. This is the single most difficult (but also fascinating) aspect of software design. I am going to guess I am not the only one who tried adding to an application with a bad feeling that this is just the wrong way. However, the right way is often just not practically or economically feasible for the time being so you go along with it. So I am afraid I for one am not worthy of your congratulations, having had to do big-bang rewrites as I got smarter, several times in my career. Also it is not uncommon to be characterized by colleagues as a gold plating perfectionist and, like it or not, the best feature of a peace of software is being able to ship it. Max, interesting post. No matter how much design you do, users will always sneak in requests and features which ends up as patches and workarounds. Eventually you start to see more and more regressions and a major refactoring or perhaps even redesign is called for. This is the single most difficult (but also fascinating) aspect of software design.

I am going to guess I am not the only one who tried adding to an application with a bad feeling that this is just the wrong way. However, the right way is often just not practically or economically feasible for the time being so you go along with it. So I am afraid I for one am not worthy of your congratulations, having had to do big-bang rewrites as I got smarter, several times in my career. Also it is not uncommon to be characterized by colleagues as a gold plating perfectionist and, like it or not, the best feature of a peace of software is being able to ship it.

]]>