tag:blogger.com,1999:blog-37274183.post3417685985919553333..comments2024-03-14T09:39:31.551+02:00Comments on Java: Developing On The Streets: Is Your Program Greener or Longer?Anonymoushttp://www.blogger.com/profile/15900841850889743147noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-37274183.post-90618010158394034362008-12-11T15:37:00.000+02:002008-12-11T15:37:00.000+02:00As I wrote this post I thought of mentioning this ...As I wrote this post I thought of mentioning this angle. I left it out just to keep the post short. So, thanks for bringing this up.... :)Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-23835175939774049772008-12-11T15:20:00.000+02:002008-12-11T15:20:00.000+02:00I think you are asking the wrong question.The ques...I think you are asking the wrong question.<BR/><BR/>The question you should ask is which way will have the better ROI in real life? <BR/><BR/>And a possible answer will go something like:<BR/>lets say you have 4 subsystems each will take about 3 month, so you dedicate a year for the product. <BR/>Starting out everything goes almost OK. You finished the first subsystem on time, and the 2nd and 3rd with a minimal 2 weeks delay.<BR/>You start working on the last one and holy shit you find out that you need 4 months to complete! <BR/><BR/>The result of this common scenario will be that at the end of the year you get only half the system done, since you only finished half of the last subsystem half of the features are not completely done. but you missed by only 2 out of 12 months.<BR/><BR/>doing it feature by feature would mean that the with the same numbers you will end up with about 80% of the system done!Lior Friedman:https://www.blogger.com/profile/09488722485273801828noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-1880339611016064842008-12-11T12:14:00.000+02:002008-12-11T12:14:00.000+02:00That is a very good point. It is the dual side of ...That is a very good point. It is the dual side of the claim that in a given subsystem the code deals with the same issues (only JDBC, only UI, etc.) so that reuse opportunities are greater with architectural decomposition. <BR/><BR/>Your claim argues that similar opportunities occur also with functional decomposition. I totally agree. Wish we had some statistics about it.Anonymoushttps://www.blogger.com/profile/15900841850889743147noreply@blogger.comtag:blogger.com,1999:blog-37274183.post-80392377093501970262008-12-10T21:58:00.000+02:002008-12-10T21:58:00.000+02:00Features in the same system, even ones that seems ...Features in the same system, even ones that seems unrelated, might share a significant amount of lines of code. On the other hand features that looks tightly coupled may actually share almost nothing. <BR/>So the LoC cost of feature F1 might be 100 and the LoC cost of F2 is 100 too, but since they share 50 LoCs then the aggregate cost is 150 LoCs.<BR/><BR/>The equivalent in sort might be a known sequence that repeats in some of the 10 arrays of 100. Say you know or can calculate the identical sequences fast enough in the combined array of 1000 elements. Then you can reduce the sorting time using quicksort like algorithm which is aware of the repeated sequences.Eishay Smithhttps://www.blogger.com/profile/09443096006184006852noreply@blogger.com