Comments on: Characteristics of "Great Software Design"TM http://www.bybjorn.com/30/ bybjorn.com >> Bjørn Børresen - freelance web developer Mon, 26 Jul 2010 13:21:06 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Sean http://www.bybjorn.com/30/comment-page-1/#comment-57 Sean Mon, 20 Jul 2009 15:11:38 +0000 http://bie.no/blog/computers/software-engineering/pragmatic-programming/2006/03/characteristics-of-great-software-designtm/#comment-57 <p>I just started learning basic programming after years working on the business side of web development / web marketing. This is an outstanding set of lessons for a newbie hacker and articulated in a way that it is easy to understand, yet fundamentally valuable. Thanks for posting!</p> I just started learning basic programming after years working on the business side of web development / web marketing. This is an outstanding set of lessons for a newbie hacker and articulated in a way that it is easy to understand, yet fundamentally valuable. Thanks for posting!

]]> By: Andy http://www.bybjorn.com/30/comment-page-1/#comment-56 Andy Sun, 19 Jul 2009 19:35:38 +0000 http://bie.no/blog/computers/software-engineering/pragmatic-programming/2006/03/characteristics-of-great-software-designtm/#comment-56 <p>"If I have one more PHP coder tell me that the MVC solution probably won’t be speedy, I will have to slashdot him physically in public."</p> <p>mind to elaborate more on this ?</p> “If I have one more PHP coder tell me that the MVC solution probably won’t be speedy, I will have to slashdot him physically in public.”

mind to elaborate more on this ?

]]> By: Austinwiltshire http://www.bybjorn.com/30/comment-page-1/#comment-55 Austinwiltshire Sun, 19 Jul 2009 18:25:58 +0000 http://bie.no/blog/computers/software-engineering/pragmatic-programming/2006/03/characteristics-of-great-software-designtm/#comment-55 <p>I definitely take note with your proclamation not to consider speed. I see where you are getting at - certainly when some argue that one of the tools of abstraction (polymorphism for example) which has an associated runtime cost should not be used, despite an utter lack of profiled evidence, I'm with you. But when you're designing a system that you well know must scale in particular directions, i.e., you expect it to be handling millions of X a second, then whatever algorithm or data structure you use to handle X needs to be built with speed in mind. This is more of the Big 'Oh sort of 'speed' rather than pure clock cycles. For many applications, such as embedded, games, scalable aps or libraries, performance should actually be on your mind from day one. It's just that many people believe performance comes from forgoing abstraction and maintainability, when real performance comes from an analysis of the available algorithms, domain specific design patterns, etc...</p> I definitely take note with your proclamation not to consider speed. I see where you are getting at – certainly when some argue that one of the tools of abstraction (polymorphism for example) which has an associated runtime cost should not be used, despite an utter lack of profiled evidence, I’m with you. But when you’re designing a system that you well know must scale in particular directions, i.e., you expect it to be handling millions of X a second, then whatever algorithm or data structure you use to handle X needs to be built with speed in mind. This is more of the Big ‘Oh sort of ‘speed’ rather than pure clock cycles. For many applications, such as embedded, games, scalable aps or libraries, performance should actually be on your mind from day one. It’s just that many people believe performance comes from forgoing abstraction and maintainability, when real performance comes from an analysis of the available algorithms, domain specific design patterns, etc…

]]>