tag:blogger.com,1999:blog-7826786244968404549.post1257805276522451154..comments2023-09-05T23:58:35.122-07:00Comments on Simple Architectures for Complex Enterprises: The Misuse of ReuseRoger Sessionshttp://www.blogger.com/profile/16946430426943308823noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-7826786244968404549.post-76633028175614772892014-10-28T03:27:26.568-07:002014-10-28T03:27:26.568-07:00> Now I should point out that I am not totally ...> Now I should point out that I am not totally opposed to reuse. There are situations in which reuse can pay dividends. <br /><br />I was forwarded this article and I know it will be used for argument against reuse, perhaps you can be more explicit in "for reuse" reasons. Personally, I find reuse of limited use.. The worst case is "Helper"\"Util" classes. But composition\delegation makes good argument for reuse. Inheritance is good for very specific cases but not much.. what do you think?Vishnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-51313914237869014982013-07-15T07:06:08.409-07:002013-07-15T07:06:08.409-07:00Hi Roger, I think your point is very valid though ...Hi Roger, I think your point is very valid though it is very situation based. And I have seen situations where people tend to forget the basic principle of architecture which is 'keep it simple' and they tend to over architect/design things. <br />Prashant Gapathttps://www.blogger.com/profile/08840382316957249226noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-86807240892208156512013-05-16T11:36:18.633-07:002013-05-16T11:36:18.633-07:00Reuse has the most bang for the buck during design...Reuse has the most bang for the buck during design. Once I learn a design that works to solve a type of problem, I will reuse it. (Some people like to give everything a name and call this design patterns).<br /><br />Reuse during construction and execution really only works for a few simple cases. For example, math subroutines. Even then, there is no agreement on what a string object should be able to do or not do. Reuse during construction and execution is hard, adds to complexity, and not be worth the effort. Look at how many packages bring their own copies of Java or DLLs.Michael Waceyhttps://www.blogger.com/profile/03124019426907972901noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-49561914034529073942012-08-20T17:31:05.993-07:002012-08-20T17:31:05.993-07:00Great discussion.
Now to focus on my particular i...Great discussion.<br /><br />Now to focus on my particular interest -- somebody comment, not on programming code of one kind or another, but reuse of data objects (pleaase).Jamesnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-45628382398738517732012-08-20T13:27:53.833-07:002012-08-20T13:27:53.833-07:00Roger, what you describe is really a practical exa...Roger, what you describe is really a practical example of the conundrum between specialisation and generalisation found in nature, where successful 'design' is always a compromise.<br /><br />You can also turn your example around to show that they biggest cost saving in IT is provided not by designing to cope with the complexity of many variations in business requirements, but to reduce those variations. That is to start with 're-use' (generalisation) in the business, then worry about re-use in IT.<br />Best wishes - Ron Anonymoushttps://www.blogger.com/profile/16371019545937942770noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-83497976672848707642012-08-20T13:26:06.663-07:002012-08-20T13:26:06.663-07:00Roger, what you describe is really a practical exa...Roger, what you describe is really a practical example of the conundrum between specialisation and generalisation found in nature, where successful 'design' is always a compromise.<br /><br />You can also turn your example around to show that they biggest cost saving in IT is provided not by designing to cope with the complexity of many variations in business requirements, but to reduce those variations. That is to start with 're-use' (generalisation) in the business, then worry about re-use in IT.<br />Best wishes - Ron<br /><br />Anonymoushttps://www.blogger.com/profile/16371019545937942770noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-53968926407551788802012-08-18T06:51:19.458-07:002012-08-18T06:51:19.458-07:00Télcio,
You raise a good point. This is a bad harm...Télcio,<br />You raise a good point. This is a bad harmonic at play. The more reusable a system is, the more complex it is. And the more complex it is, the more it is likely to fail. And the more the system has been reused, the greater the impact of that failure.<br />- Roger<br />Roger Sessionshttps://www.blogger.com/profile/16946430426943308823noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-55378152198161042742012-08-18T06:21:54.852-07:002012-08-18T06:21:54.852-07:00Thank's for sharing Roger. I do agree with you...Thank's for sharing Roger. I do agree with you that complexity is an important point to be taken into account when reusing code. We have also to take into account that as much complex the functionality is, more impact in the system as a whole it causes if changed. If we don't have a good control of these points where we reused it, we will have some headache. So, even tough reusing code could save money, we may have to spend more time analyzing the impacts when changes are necessary and, this time costs money.<br /><br />Regards,<br />Télcio CardosoTélcio Cardosohttps://www.blogger.com/profile/10197765166137500160noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-84662798878546024722012-08-18T06:20:56.099-07:002012-08-18T06:20:56.099-07:00Thank's for sharing Roger. I do agree with you...Thank's for sharing Roger. I do agree with you that complexity is an important point to be taken into account when reusing code. We have also to take into account that as much complex the functionality is, more impact in the system as a whole it causes if changed. If we don't have a good control of these points where we reused it, we will have some headache. So, even tough reusing code could save money, we may have to spend more time analyzing the impacts when changes are necessary and, this time costs money.<br /><br />Regards,<br />Télcio CardosoTélcio Cardosohttps://www.blogger.com/profile/10197765166137500160noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-49994701164467211502012-08-18T06:19:50.310-07:002012-08-18T06:19:50.310-07:00Thank's for sharing Roger. I do agree with you...Thank's for sharing Roger. I do agree with you that complexity is an important point to be taken into account when reusing code. We have also to take into account that as much complex the functionality is, more impact in the system as a whole it causes if changed. If we don't have a good control of these points where we reused it, we will have some headache. So, even tough reusing code could save money, we may have to spend more time analyzing the impacts when changes are necessary and, this time costs money.<br /><br />Regards,<br />Télcio CardosoTélcio Cardosohttps://www.blogger.com/profile/10197765166137500160noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-91257454744279226222012-08-18T06:18:56.696-07:002012-08-18T06:18:56.696-07:00Thank's for sharing this point o view Roger!
...Thank's for sharing this point o view Roger!<br /><br />I do agree with you that complexity is an important point to be taken into account when reusing code. We have also to take into account that as much complex the functionality is, more impact in the system as a whole it causes if changed. If we don't have a good control of these points where we reused it, we will have some headache. So, even tough reusing code could save money, we may have to spend more time analyzing the impacts when changes are necessary and, this time costs money.<br /><br />Regards,<br />Télcio CardosoTélcio Cardosohttps://www.blogger.com/profile/10197765166137500160noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-16259893174712597312012-08-15T17:51:46.961-07:002012-08-15T17:51:46.961-07:00"Great Post"
I must say it as one of th..."Great Post"<br /><br />I must say it as one of the "Best" articles I have read. Probably I liked it more as it is in sync with the principles I believed in and used to share with others. The beauty of this article is that way it is structured and articulated. Also, I would like to add a few notes from one of my work-in-progress articles on my blog - http://beyondyourcode.com.<br /><br />-- As far as making architectural and design decisions, add this simple rule "Return On Investment" to your "Design Requirements". It is most of the times from the technical point of view like maintainability, extensibility. But you should try to add a business sense as well - "How does the customer benefit from this or otherwise?". Take a common businessman approach - "If I spend 2 days in coding better using reusability, would it save me 10 days later on?".<br /><br />-- I liked the point that the 'reusability is not the goal and it is just a path'. It should come out by itself per the behavior of the problem which is followed by the behavior of the program.Anonymoushttps://www.blogger.com/profile/09043708172627502148noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-55194619762848180162012-08-07T08:27:08.735-07:002012-08-07T08:27:08.735-07:00Code reusability is not the target, it's just ...Code reusability is not the target, it's just an expected result of good programming.<br /><br />When you create solution for case A and then working on case B which is quite similar, a good solution should be generic, covering both cases A and B. And that would usually result in reusable code, class, library, script, service, etc. <br /><br />The same could be applied to simplicity, it's not the target, it's an expected result of good programming.<br /><br />Reusability and simplicity are not mutually exclusive, and often are caused by proper code refactoring and optimization.<br /><br />I think we are on the right track, software solutions and tools are evolving.Stereo DDDhttps://www.blogger.com/profile/17720274512283292663noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-38453652919551993332012-07-26T04:49:49.239-07:002012-07-26T04:49:49.239-07:00Brilliant article. After more than 20 years workin...Brilliant article. After more than 20 years working in IT, I totally agree!Explobothttps://www.blogger.com/profile/14357524085622946370noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-46781233796346964652012-07-20T07:21:16.834-07:002012-07-20T07:21:16.834-07:00well saidwell saidAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-40177064944135091322012-07-18T18:55:22.616-07:002012-07-18T18:55:22.616-07:00I agree with the points made in the post. However...I agree with the points made in the post. However, Reuse is not only a tool used to reduce initial development costs, it is also a tool used to achieve increased maintainability on an ongoing basis. If a change is needed, it only needs to be done once, versus many times. The problem is, this can also result in an unintended side effect of increased testing cost resulting in increased time to market anytime that shared code needs to be modified. So I think another factor to be considered for reuse is an estimation as to how frequently that shared bit of code would need to be modified.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-38800579257035160532012-07-12T21:45:49.605-07:002012-07-12T21:45:49.605-07:00The article only focusses on software programming ...The article only focusses on software programming & code reuse. In actual practice, reuse occurs over all other phases of the software project also in addition to Development: Systems Analysis, Design, Testing, Implementation & Maintenance.<br /><br />Mahesh Khatri.Mahesh Khatrihttps://www.blogger.com/profile/12156236856042865527noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-63542354059938038862012-07-12T07:04:11.438-07:002012-07-12T07:04:11.438-07:00A good, thought provoking article!
A few points, t...A good, thought provoking article!<br />A few points, though.<br />A lot depends upon what you mean by 'reuse'. If we consider ‘reuse’ and ‘complexity’ in isolation, or in too narrow a sense, we miss many opportunities for architecture to add value to software development and for getting good software to market quickly.<br />I think we have been doing pretty well with 'reuse' of one kind or another over the past 40 years.<br />For example POSIX has had a measure of success in ensuring that code is portable across different operating platforms, enabling C library implementations to be written that enable application programmers to perform both 'complex' and 'simple' tasks using standard system calls. The BSDs and Linux have been ported to many platforms, from z390 mainframes to Android phones with enormous code reuse.<br />More recently, we have seen the rise of projects, such as Eclipse, Struts, Hibernate, JSF, Camel and a host of others with masses of portable, re-usable code, all of it free (as in 'beer' and as in 'freedom') some of it doing 'simple' stuff and some of it doing more 'complex' stuff.<br />I think that what trumps everything is 'cost effectiveness'. In other words, what delivers the required functionality to market with the best overall combination of time, cost and quality? This is, after all, what our customers expect and are paying us for. They want good features in their hands, in good time, at a good price.<br />For example, for our next world-beating shoot-em-up, we may 'reuse' PC hardware and firmware and a particular operating system. We will probably 'reuse' an IDE, a physics engine and maybe some rendering and animation software. On the other hand, we may discover that a critical bit of our polygon rendering subsystem just won't cut it in today's market and we have to hand-code that bit in assembler ourselves; it’s complex and difficult, but it will beat the competition and bring the money in. And we can 'reuse' the assembler and the shared library we’ve developed on this project and sell it on to others. Maybe we have been enlightened enough to save a lot of legal costs and 'reuse' the GPL, release our code under that and make money doing support and consultancy. Maybe this is a big project and we need to 'reuse' our Human Resources department and the services they provide (including the HR system that helps us get a programmer’s bum in a chair more quickly). We may also succeed in 'reusing' agile software development techniques and 'reusing' established supply chains to market and distribute our software.<br /><br />I think that architects really earn their pay when they understand the many types of use/reuse, complexity/simplicity and come up with a good blueprint aligning everything to deliver the best time-to-market/cost/quality combination.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-16119323799444800762012-07-12T00:25:44.473-07:002012-07-12T00:25:44.473-07:00Design patterns?Design patterns?4thAugust1932http://goo.gl/NFK0Anoreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-33474403778690799452012-07-11T17:52:22.701-07:002012-07-11T17:52:22.701-07:00. It’s always tough to generalize.
.
. Actually .... It’s always tough to generalize.<br />.<br />. Actually the first and leading use (Fortran II?) of reuse was with subroutine libraries and by any measure has been highly successful.<br />. <br />. The particular guideline “In general, a reuse strategy is indicated when the inherent complexity of the functionality being shared is high and the usage of that functionality is relatively standard” is particularly misleading. Consider for instance a square root routine. Simplicity of functionality and amount of use are important.<br />.<br />. In any case, principals of design that support reuse are always useful, since a major use of reuse is maintenance. Without this maintenance and evolution quickly leads to patch work and can eventually lead, when reuse is no longer possible, to total replacement of systems.Anonymoushttps://www.blogger.com/profile/00679308956018638185noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-18523192188052261042012-07-10T05:41:47.007-07:002012-07-10T05:41:47.007-07:00Jeremie, Good thoughts. Although from my perspecti...Jeremie, Good thoughts. Although from my perspective, complexity and simplicity are exact opposites. But there are other attributes similar to simplicity that are also important, such as elegance.<br /><br />Glenn, I'm not familiar with SEI's Software Product Lines.Roger Sessionshttps://www.blogger.com/profile/16946430426943308823noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-58990884599890190052012-07-10T00:12:51.674-07:002012-07-10T00:12:51.674-07:00Have you heard of software product lines? This is ...Have you heard of software product lines? This is SEI's attempt to find the sweet spot between complexity and reuse.Anonymoushttps://www.blogger.com/profile/09272899150919990489noreply@blogger.comtag:blogger.com,1999:blog-7826786244968404549.post-51262632494907934192012-07-06T09:14:51.807-07:002012-07-06T09:14:51.807-07:00Great article about the IT graal:"reuse"...Great article about the IT graal:"reuse".<br /><br />For the same function in 3 different systems, I think there is no one model to rule them all: actually there are possibly 3 contexts at play with the 3 systems. As described in Domain Driven Design, each model is tied to a context (a context is the environment that set the meaning of a word).<br /><br />But that's right simplification is the key: here are my thoughts about complexity and simplicity (with some thoughts borrowed from Rich Hickey) <br />http://www.zenmodeler.com/design-matters/software-design/simple-and-easy-software-design-qcon-london-2012Jérémie Grodziskihttp://www.zenmodeler.com/design-mattersnoreply@blogger.com