Why I abandoned MetricFu

My last commit to MetricFu was March 2...  of 2011. 

So.
much.
shame.

Since I am throwing in the towel and handing over leadership (perhaps to you), I thought I should explain why I've been such a terrible maintainer and why I'm walking away.

Reasons:

  • 1). MetricFu is a mess.  At some point, with all the submissions coming in, the architecture and testing got away from me.  Now it's pretty depressing to see crap code quality in an app that is supposed to be about good code quality.  I can not overstate how embarrassing and frustrating this is – mostly because it's my fault (I let in things I shouldn't have. Stupid feature blindness).
  • 2). In 2008, when I created MetricFu, I was fascinated by metrics and now I'm not because I don't need the tools to see the problems anymore.  Metrics made me better but now I'm leaving them behind:  Selfish.
  • 3). I'm not a consultant at the moment so the exploratory nature of MetricFu isn't very useful to me.  I know where the bad parts of town are in my app.
  • 4). I think metrics can be a great teaching tool, but you can learn all the wrong things if you're not careful. You can reduce Flog scores without making the app better (Simple: arbitrarily divide up every large method) . Same with code coverage. Even code duplication detection can lead to bad code.  DRY-ing things up in a bad way can often be much more harmful then leaving them moist (perhaps you removed some duplication by creating a crazy amount of indirection – a common problem).
  • 5). Ultimately, creating software is a craft.  It's not pure science and it's not pure art, it's a combination of both.  MetricFu leans a too little hard toward numbers and that implies a precision we just don't have. How to get from bad code to good is a very delicate dance between content, form, and business requirements.
  • 6). Integrating over a dozen meta-code gems is a god damn pain.  The gems that make up metric_fu use code to analyze code (intense meta Ruby) and so they sometimes conflict.  Also since MetricFu mostly uses regexes to parse the (command line or html) output, every change in one of MetricFu's underlying gems means that MetricFu needs a version bump. 
  • 7). The last year has been, personally, very busy and difficult for me.
For these reasons I'm going to be stepping aside as metric_fu maintainer – I'll still be around to answer questions and such but I probably won't be contributing much code.  If I've somehow disappointed or frustrated you because of last year's neglect then I apologize. Seriously.  I'm sorry.

Want to lead MetricFu? Make your case in the metric_fu google group:
https://groups.google.com/forum/?fromgroups#!forum/metric_fu

Comments

Anonymous said…
Wow, I really appreciate your clear words !
I can follow your argumentation, completly.
All the best.

Bye
Jo
August 9, 2012 at 8:12 AM
Anonymous said…
Don't be so tough on yourself, Jake! metric_fu was a great achievement and you should be proud of yourself.
August 9, 2012 at 1:36 PM
tea42 said…
In a way it is too bad. At its peek you probably could have used the metric-fu's clout to bludgeon the heads of developers of the underlying tools to support YAML output formats. This would have made support much easier.
August 10, 2012 at 11:53 AM
DanMayer said…
Sorry to see you go, I understand maintaining something over a long time especially when your interests move on is hard. To be honest, I also completely understand how HARD metric-fu is to maintain with so many integrations and changing dependancies. Also, your line "now I'm not because I don't need the tools to see the problems anymore" completely resonates with me. Thanks so much for the awesome project, I hope some in the community will help step up to bring it forward a bit. I will try to support it a bit when I can.
August 10, 2012 at 8:59 PM
DanMayer said…
Sorry to see you go, I understand maintaining something over a long time especially when your interests move on is hard. To be honest, I also completely understand how HARD metric-fu is to maintain with so many integrations and changing dependancies. Also, your line "now I'm not because I don't need the tools to see the problems anymore" completely resonates with me.

Thanks so much for the awesome project, I hope some in the community will help step up to bring it forward a bit. I will try to support it a bit when I can.

Good luck on all the new projects that intrest you and the awesome things you build in the future.
August 10, 2012 at 9:00 PM
Justin Beck said…
I've always appreciated your work on metric_fu... It made me a better ruby developer and a better coder in general. Thank you for that!
August 14, 2012 at 7:30 AM
OJ said…
I have a working version here: https://github.com/bf4/metric_fu
September 5, 2012 at 1:52 PM
Benjamin Fleischer said…
I have a working version here: https://github.com/bf4/metric_fu
September 5, 2012 at 1:53 PM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more