This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The Mikado Method vs Software Architecture

 
Ivano Pagano
Ranch Hand
Posts: 54
Java Mac OS X Scala
  • 0
  • Mark post as helpful
  • send pies
  • 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
     
    David Sachdev
    Ranch Hand
    Posts: 32
    • 0
    • Mark post as helpful
    • send pies
    • 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.
     
    Ola Ellnestam
    Author
    Greenhorn
    Posts: 10
    5
    • 0
    • Mark post as helpful
    • send pies
    • 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: 54
    Java Mac OS X Scala
    • 0
    • Mark post as helpful
    • send pies
    • 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
     
    Jim Young
    Greenhorn
    Posts: 6
    Linux Netbeans IDE Oracle
    • 1
    • Mark post as helpful
    • send pies
    • 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
     
    I agree. Here's the link: http://aspose.com/file-tools
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic