Additional Material

7 views
Skip to first unread message

Dr. Eck

unread,
Sep 28, 2010, 11:25:46 PM9/28/10
to Mikado Method
I read the August version of the book and was quite pleased. The
Mikado Method appears to be the kind of tool I need to help with my
maintenance work on 300k lines of 1980's C code. Because your book is
one of very few (2?) available books on dealing with legacy code, I'd
love to see you generalize it slightly and at least describe other
methods. The only other methods I know of are Michael Feathers' seam
method and Martin Fowler's Strangler method. Are there others that
work? How does the Mikado Method compare and contrast? When are each
of the methods best applied? When is it time for a rewrite?

I also ran across an interesting blog by Eric Ries titled "Refactoring
Yourself Out Of Business" that has some wisdom you might want to
reference.

I'm very thankful to InfoQ for referencing your book and to you for
writing it.

Daniel Brolund

unread,
Sep 29, 2010, 8:21:56 AM9/29/10
to mikado...@googlegroups.com
Dr Eck,

Thank you for your feedback!

We would be happy to hear about your experience with the Mikado Method
on the C code you mention.

I would say that the Mikado Method is a complement to the previous
work by e.g. Fowler and Feathers.

For instance, finding or putting in seams i a common thing to do when
changing your code, as a part of your Mikado. I would say that seams
is related to the Dependency Inversion Principle, Inversion of
Control, the Liskow Substitution Principle, and the mocking/stubbing
technique. We need to give it a thought and see if we can put in
references to e.g. seams in the book where it makes sense. Any hints
from you readers of where in the book you would like to see it would
be of good help!

When implementing a Strangler Application the Mikado is of great help,
at least from my experience with strangling smaller parts of an
application.

I also read the blog by Eric Ries, and it was an interesting read. I
think the Mikado Method is extremely well suited for such a situation
where you have to 1) minimize the time spent on refactorings and 2)
keep delivering business value in the process. 1) is supported by the
Naive approach where you only fix the prerequisites you must for a
specific feature, and 2) is due to the fact that you only make small
changes at a time, always allowing you to implement and deliver new
features at any time.

Thanks again!

Cheers
Daniel

P.S. Please, provide us with your full name for the reviewers section
in the book. Otherwise, we will call you Dr Eck. :-)

> --
> You received this message because you are subscribed to the Google Groups "Mikado Method" group.
> To post to this group, send email to mikado...@googlegroups.com.
> To unsubscribe from this group, send email to mikado-metho...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mikado-method?hl=en.
>
>

--
---------------------------------------------------------
Daniel Brolund
Agical AB - www.agical.com

work: daniel....@agical.com
phone: +46708754002
blog:http://danielbrolund.wordpress.com
twitter: @danielbrolund
private: daniel....@gmail.com

Reply all
Reply to author
Forward
0 new messages