What is the most valuable principle in design? RRS feed

  • General discussion

  • In looking at SOA, earlier component based design, separation of concerns, etc. It seems to me that architecturally they can all be lumped in to various flavors of abstraction. So, it occurs to me and seems to hold true in my designs that the most valuable principle in software design is abstraction. Does anyone feel that a different principle is more critical?

    Are there different schools of thought (SOA, SOC, Interface based design, etc.) that are contradictory when dealing with abstraction?

    New to the forum, but have been wanting to talk with people that make an effort to further their design knowledge.
    Saturday, February 17, 2007 1:04 AM

All replies

  • If you think about why we design software at all, I think maintainability is the paramount reason. We want to be able to change every single decision we've made when building the software to fit real life changes such as changes in requirements (functional of other), hardware, external dependencies, the developer team, etc...

    In trying to achieve this goal, the most valuable principle is called OAOO (once and only once) or DRY (don't repeat yourself). If you make sure every single decision regarding the nature of the software exists in one place and is decoupled from any other decisions, you've achieved ultimate ease of maintainability.

    Abstraction is a means to that end and a very important one, but there are others.
    Saturday, February 17, 2007 8:06 AM
  • Hi EastShores,

       I agree with Yoni that, despite Abstraction is a valuable architectural principle, surely it will depend on a trade-off among different interests what will determine the principles of an architecture

       In isolation, every principle is idealistically desirable, but reality often imposses other priorities. I like a comment made by Mike Platt, architect of the Microsoft Architecture Team, days ago. He was talking about abstraction as something to achieve, but he said with respect to Abstraction things like "Creating abstract models is something very easy. What is difficult is achieving the right level of abstraction, a level which every stakeholder in the organization can understand when drawn in a whiteboard"

       Colateral with this I want to invite you to read a series that Ted Neward is writting about Pragmatic Architectures. He started talking about Layering and Security, and a third article about User Experience is comming


       Hope you enjoy it

    Monday, February 19, 2007 4:23 AM
  • To me  the most valuable design principle is practicality  - you need to design something that can be made to work. To do this you need to be pragmatic (as Diego mentioned). A "perfect" solution that cannot be realized because there isn't enough time (for example) is just as bad as an awkward design

    The trick, so to speak, is to know to balance the different design principles, requirements and constraints and to be able to create a viable architecture


    Monday, February 19, 2007 8:36 AM
  • For me, principles are really situationally specific.  I think what is more fundamental is axioms that apply across all situations.  In that regard I believe that the axiom, Keep it simple stupid (KISS) is the most valuable axiom that an Architect can learn.  More often than not, when people try to "get cute" or "fancy" things tend to blow up.



    Tuesday, February 20, 2007 2:22 AM
  • I am an architecture student in Egypt, and i started my first project about a vacation house, can anybody help me with what to do or where to read to form an excellent plan and elevations....thank u
    Tuesday, February 20, 2007 5:06 PM
  • To me, the most valuable principle in design is KISS (Keep it simple, stupid) principle. Especially these days in which everywhere full of fancy frameworks and technologies.

    This is because, most people are unsure and confused about those frameworks and technologies. However, people should be aware of incorporating those technologies that generates additional dependencies which, in turn, expose more bugs.

    So a good architecture should be as simple as possible but no more simpler than that (modifed Einstein speech:D ) Those are the great architects for me.


    Ekrem Aksoy

    Tuesday, February 20, 2007 8:01 PM
  • Hi sHERIF,

       actually the topic we are discussing on is Software Architecture, a discipline of Software Engineer with lots of analogies with urban architecture (but thought for software building purposes instead of house building)  

    Wednesday, February 21, 2007 4:39 AM
  • I disagree with you EAX (with all respect of course).

    KISS may be right for your own tool that you use to solve a simple or tiny problem that does not involve lot's of people using it.
    A tool that will throw "Unhandled exception" when people other than yourself use it :S
    For example b4 .Net2.0 I created my own little tool to generate TypedArrayList such as IntList, MyClassList etc...just to avoid casting every element,
    and to be able to add some useful funtionalities that are not available within the ArrayList.
    In such a case u don't care about a sophisticated design...u can keep it SIMPLE as much as u need for UI, just a command prompt is more than enough,
    you don't need layering...

    However, when you design a real life application and get tons of requirements from your client who wants the same functionality to be performed in different ways.
    You can't tell him it is not a KISS anymore, because he owns the money:) You have to design in a very flexible way because you should be certain that he will keep calling you asking for new features (sometimes contradicting)

    Wednesday, February 21, 2007 7:49 AM
  • Hi,

    I think you misunderstood my explanation on KISS. KISS is neither being non-extensible nor UI-less design. My point with KISS is just focusing on the requirements (that will probably evolving thru-project) and developing just what is needed. Many people got "Unhandled Exceptions" and keep roaming around the code like hens because they can't get the actual reason for it. Probably, this is because of the stack APIs like we see in everyday Java (nope, I'm not trying to abuse...just try 1.4.2-to-6 swing application refactoring for instance or use axis to develop Web Services)

    So, if extensibility and smart UI is needed (or Smart Clients, for instance) the KISS principle is to develop an extensible application with Smart Client. What I'm against for is just abusing and misusing of frameworks in the name of "using XXXXX framework". (Indeed, I'm not against spring, hibernate or any other frameworks) Beside, it should be noticed that including those frameworks creates additional dependencies.

    As a matter of fact, I'm using this principle to develop ERP DSL and Framework everyday which, I believe, is not a simple or tiny problem with few users.


    Ekrem Aksoy

    Wednesday, February 21, 2007 8:14 AM
  • Hi again,

    <<Well it would be interesting to have a look on Java again after 1.4.2 (this is the last version I have used).>>
    Anyway, although you have a point regarding the growing complexity of APIs but I guess you don't really have the choice.
    Usually you add APIs whenever u have to add new functionalities WHICH ARE ALWAYS REQUIRED BY CLIENTS.

    Take this simple example where in an application one can create users, groups and assign users to the groups. To keep it simple, a developer makes a form to create the user, another to create a group and assign users to it. This might not be enough for the customer.
    He might want something more, like assigning several groups to the user from the user form.
    While the 1st method workds fine and kept the logic simple, the addition of the 2nd method (although not catastrophic in this example) will surely add more complexity to the problem.

    It is also worth mentioning that developing frameworks by third party is usually less problematic, and the KISS might work better. The reason is that you don't have to add a complex functionality if this functionality can be performed by several calls to existing functions.

    Wednesday, February 21, 2007 9:50 AM