Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^3: Random quotes in the top left corner

by tilly (Archbishop)
on May 01, 2005 at 01:24 UTC ( [id://452948]=note: print w/replies, xml ) Need Help??

in reply to Re^2: Random quotes in the top left corner
in thread Random quotes in the top left corner

I think that your conclusion, as appealing as it may be, is wrong.

The time when tighter coupling makes sense is when you are pushing the frontier of what is possible. In that situation attempting to enforce loose coupling pushes you to choose a way of modularizing before you understand the problem space well enough to pick a good modularization. Maintaining it also prevents you from using certain optimizations that you might come up with after you create your design.

This does not mean that people who are trying to accomplish the novel have free license to throw out the rule-book. To the contrary they are unlikely to successfully push those limits unless they try hard to make the complexities that they will encounter manageable. However they will also need to selectively violate normal principles just to make what they want to do possible.

However history shows that, when technology catches up to what they were trying to do, the people who created the integrated technology generally lose in the long run to latecomers with more modular technologies. Does this mean that they did something silly? Not at all! History suggests two other things as well. The first is that the recognition of the right way to modularize the problem is often only possible after someone has solved it badly, first. The second is that there is a lot of money to be made by being the first to be able to do something that people want to do.

For more on this, I highly recommend The Innovator's Solution. Be warned, it is a management book and not a technology book per se. However I think that what it has to say about which technologies are likely to replace others is useful for people who work with technology.

  • Comment on Re^3: Random quotes in the top left corner

Replies are listed 'Best First'.
Re^4: Random quotes in the top left corner
by apotheon (Deacon) on May 01, 2005 at 03:50 UTC

    I don't think I'd say that my "conclusion" was "wrong" so much as that it was incompletely stated. To round it out nicely, I should have made reference to the idea that first, one should create a throw-away.

    I know that the idea of creating a throw-away version first is an oft-cited principle of software design in general, but it applies even moreso to innovations: first, you innovate, then you create something useful. Sure, tightly couple in the throes of creative frenzy if you must, but then recreate your innovation with more modularity. There's a big difference between screwing around with new ideas and writing good code.

    So, yeah, I think that tight coupling has its place in experimenting with new ideas, but that doesn't mean you should be calling something a release version before you've refactored and restructured so that it's more modular.

    But, again, I could well be speaking too vehemently of things I don't understand well enough. Considering our relative levels of experience with Perl code, I'd be inclined to say that, all else being equal, yours is more likely the "right answer" than mine.

    print substr("Just another Perl hacker", 0, -2);
    - apotheon
    CopyWrite Chad Perrin

      I still disagree. In real world cases tightly integrated designs have often been viable a decade or more before modularized designs came to market. This is not a question of building a throw-away (though your solution will be superceded once raw performance isn't as important as, say, customizability), it is a question of being able to create the right product at the right time.

      Let's look at an analogous situation comparing languages rather than development techniques. Suppose that Perl is 10x slower than C. But it is clearly preferable to accomplish a speific task in Perl. Then from Moore's law we can project that it will be feasible to do that task in C about 5 years before it is feasible to do it in Perl. The C solution will be doomed, eventually someone will do it in Perl and the Perl solution will be more flexible and customizable and will win. However the C solution will not be a throw-away, it will be able to meet a need before the Perl one could. Furthermore with the 5 year headstart on development, the C project could easily remain better than Perl for several years after CPUs become good enough for the Perl solution. So for perhaps a decade, despite the obvious reasons to prefer Perl, everyone will use a solution built in C.

      The same thing happens with modularization. For instance in the mini-computer market, the first successful operating systems (Apollo, VMS, etc) were tightly integrated with the hardware. Eventually they all lost to Unix, which was significantly more modular in design. But they were not throw-away solutions, and for many years was what everyone used.

        I still disagree. In real world cases tightly integrated designs have often been viable a decade or more before modularized designs came to market.

        You seem to be implying (and please correct me if I'm wrong ;-) that loosely coupled systems are necessarily slower to market and/or perform significantly worse than tightly coupled solutions?

        If so, I'm not entirely convinced. When I see tightly coupled software being produced it's normally a combination of one or more of:

        • Developers not having the necessary knowledge of ways to create software in a loosely coupled manner (e.g. not knowing about techniques like dependency injection.)
        • Not having appropriate tools to make the development of loosely coupled software simple (e.g. a language like Perl or Java offers more features that help with loose coupling than a language like C or COBOL.)
        • Not having experience of software development practices that encourage loosely coupled software (e.g. using TDD.)

        Sure - there are some instances where a tightly coupled system has been deliberately chosen due to some constraint - but they seem rare in my experience. More often they're done first because that's the only way the developers know how to create software.

        I have a couple of problems with your explanation.

        First, the performance and rapid development gains in tight coupling typically aren't as significant (and, in the case of rapid development, perhaps aren't even typically extant) as they are for simply choosing the right tool (language) for the job. The analogy you provide doesn't strike me as being particularly viable.

        Second, the importance of incremental performance gains from tight coupling decreases over time as system performance capability increases. The reason that UNIX was able to overcome less modular designs didn't have so much to do with the fact that less modular designs were superseded as the fact that less modular designs were no longer a simple necessity of hardware restrictions. I tend to think that as system performance capability increases, we'll see further evolution toward modularization, and what we think of as loose coupling today may be classed as tight coupling in a few years.

        Older, less modular OS designs didn't develop so much because they provided a simpler path toward development as because A) greater modularity in design hadn't really been experimented with very much yet and B) more modular design simply wouldn't run on the comparatively limited hardware available at the time.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://452948]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (7)
As of 2024-06-15 13:42 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.