• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The Mikado Method vs Software Architecture

 
Ranch Hand
Posts: 56
Scala Mac OS X Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello to the book authors.

I just had a glimpse or two of the general approach, and I actually have a couple of questions.

  • 1. What you feel is most specific to the mikado method with respect to other agile methodologies, what is the main point in using it instead of a general approach to problem solving?
  • 2. From a first look I'm tempted to say that the mikado approach can get in opposition to sound software architecture. If I understand it well, when I start working on a specific goal and try to reach it, I'm not supposed to know about the whole system design if it's not directly connected to the goal at hand. But shouldn't I know about the whole picture to avoid that each developer creates ad-hoc solutions for single features, eventually creating a system that, though being fully functional, becomes ever more unmanageable.
    Doesn't each successive goal become more hard to solve? How does the method handle system decomposition, components decoupling and similar issues without having a more holistic approach?


  • Thank you so much for any clarification
    Ivano
     
    Ranch Hand
    Posts: 92
    Mac Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ivano Pagano wrote:Hello to the book authors.
    If I understand it well, when I start working on a specific goal and try to reach it, I'm not supposed to know about the whole system design if it's not directly connected to the goal at hand. But shouldn't I know about the whole picture to avoid that each developer creates ad-hoc solutions for single features, eventually creating a system that, though being fully functional, becomes ever more unmanageable.
    Doesn't each successive goal become more hard to solve? How does the method handle system decomposition, components decoupling and similar issues without having a more holistic approach?[/list]

    Thank you so much for any clarification
    Ivano



    I too am curious to know about how much of the whole picture you are seeing (or not) with this approach. I'll admit I'm one of those that likes to spend a little extra time looking at the big picture before diving in. And it may take me a bit longer to get started on a dev project, but I think I tent to get it finished correctly faster because of it.
     
    Author
    Posts: 10
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    David Sachdev wrote:

    Ivano Pagano wrote:Hello to the book authors.
    If I understand it well, when I start working on a specific goal and try to reach it, I'm not supposed to know about the whole system design if it's not directly connected to the goal at hand. But shouldn't I know about the whole picture to avoid that each developer creates ad-hoc solutions for single features, eventually creating a system that, though being fully functional, becomes ever more unmanageable.
    Doesn't each successive goal become more hard to solve? How does the method handle system decomposition, components decoupling and similar issues without having a more holistic approach?[/list]

    Thank you so much for any clarification
    Ivano



    I too am curious to know about how much of the whole picture you are seeing (or not) with this approach. I'll admit I'm one of those that likes to spend a little extra time looking at the big picture before diving in. And it may take me a bit longer to get started on a dev project, but I think I tent to get it finished correctly faster because of it.



    Ivano and David,

    We have found that analyzing code and especially the steps of a code change can be very frustrating but also time consuming. No matter how long you analyze the code there's almost always something that you miss.

    The Mikado Method doesn't help you design, decompose or decouple code in itself, it helps you surface difficult to see dependencies by systematically and empirically trying to achieve a goal and changing code. That is you try things and then revert. It doesn't tell you exactly how to solve the dependencies and design flaws, it just points your eyes towards the issues.

    It does a great job however in helping you uncover the restructuring map and reducing the cognitive load on you brain.

    Also, If you are in a team setting, which I suppose most of us are, then showing a restructuring map (i.e the Mikado Graph) to another team member makes problems/solutions easier to discuss and identify.

    In short; the method doesn't help with design, that you have to learn elsewhere. It points to things that needs to be taken care of before you reach your goal and its prerequisites and their prerequisites and so on.

    //Ola

     
    Ivano Pagano
    Ranch Hand
    Posts: 56
    Scala Mac OS X Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks, Ola
    your answer was pretty clear.

    I'd say it's a pragmatic and light approach to code tickling.

    Ivano
     
    Greenhorn
    Posts: 6
    Netbeans IDE Oracle Linux
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    All,

    As a person who's primary responsibility is maintaining several legacy application, I am very interested in the Mikado Method.
    We have one application that is a tool set used in the company business. It requires frequent additions and modification as projects are added and changed.
    I wanted to comment on Ola's reply. To make future code changes easier I am often looking to refactor the code to reduce dependencies. I see this method as a way to help this effort and improve the initial design of the code. Great discussion.
    Jim
     
    reply
      Bookmark Topic Watch Topic
    • New Topic