Michael Feathers

Sensory Modes in Programming

Today I got caught up reading a back and forth in twitter about a proposed assertion syntax for Ruby testing frameworks.  It was interesting, but yet again it was about how to make tests 'read well.'  It's hard to disagree with that, right?  Well, I don't in principle, I just think about the amount of time we spend trying to warp programming syntax into English and I wonder whether it is really worth it.  If it is, maybe we need more malleable languages.. more malleable than Ruby.  Or, maybe we don't.  Maybe it's just too much fun.. maybe there's too much 'game' in molding an existing language into what we want it to be.  But, I'm getting off topic.

The thing I wanted to blog about is the clash between this natural language style of programming and the other sorts of programming we do.  In the agile community, seeded by Kent Beck and Ward Cunningham, there is this meme that the code should tell a story.  Luckily, our languages are nimble enough to help us with this.  We can use evocative names and string together code lines so that they read like a book.  Yes, it's work, but it is very doable.  OO was made for that sort of thing. 

Let's look at an alternative (avert your eyes if you must):

`git log #{@filename}| grep ^commit`.split(/\n/).map(&:split).map {|fields| fields[SHA1_COLUMN] }

This is a line of code that I wrote to pull the sha1s out of the output of a git log command.

Ugly?  Yes, but I can make it better.  Let's pull out the bash by saving the shell call's result into a variable called 'text':

text.split(/\n/).map(&:split).map {|fields| fields[SHA1_COLUMN] }

Better?  No, I can still hear you saying "yuck!"  I'm not going to argue with you, but I am going to say that that I think that this code is an example of an equally valid mode of expression.  It's just a visual mode rather than a narrative one.  

Let's bring it home.  Try to explain the code out loud: "take the text and split it into lines, then split those lines into fields and map each line to the field containing the sha1." 

Maybe some people do sub-vocalize that sort of thing to themselves when they see code like that, I just know that I don't.  When I see code like that, I construct a picture of what it is doing inside my head.  Words don't play into it much.

I don't think I'm alone in this.  We have different ways of making code understandable and making it 'read like English' isn't the only way. 

I remember years ago reading about something called Neuro-Linguistic Programming, and although I felt that much of it was popularized off the deep end, the idea that they had that we have different cognitive modalities is something I'll always remember.  According their theory, some people are far more visual.  Others prefer to get information in an auditory way, and often they subvocalize when they are thinking.  

No doubt this is a ruthless simplification, but what I notice about programming is that there aren't really any fixed boundaries.  We go back and forth between more structural (a.k.a functional, visual) ways of thinking about code and more narrative (auditory) ways. 

When I look at really good functional code (and believe me the piece I have up there isn't a good example) there is a balance between good naming and structure that reveals computation. 

It just isn't narrative. 

It's a different mode and I think we have to recognize it. 

Brutal Refactoring

Every once in a while, people ask me whether I'm going to do a 2nd Edition of 'Working Effectively with Legacy Code.'  I've dodged the question for quite a while because, on the one hand, it would be nice to move on.  There are so many other things I'm interested in.  On the other hand, I've learned a lot since the book was published and it would be a shame to just let that all slip away. 

These days, I'm much more aggressive in my approach to old code.  WELC was fully ingrained in that "if we don't have tests, we can't do much" attitude.  I think that part of that was a sign of the times, and part of it was a reflection of my natural fear as a consultant.  You walk in and you don't know anything about the code base so you can't even come close to accurately assessing risk.  Nicely, though, people who are embedded in teams often can, and I've learned a lot from people who've tried things out long term in their code and have lived to tell the tale.   

Beyond that, I've also learned at a deep level that what we call ugly code is really just code that was shaped by different forces.  It's always going to bear the mark of those forces and we have to go with what is there. What software wants to be is often very different from what we want it to be.  It turns out that by recognizing and aligning with these forces we can gain some leverage. Some of the funk we see in out existing code isn't going to go away, but that doesn't mean that we can't get out the pruning shears and make some rather large changes to make it all manageable.

So, what I've decided to do is organize the material I have and build it up into another book.  The working title is Brutal Refactoring.  The goal is describe how to take the big steps that make things easier and how to deal with software in the transition.  Along with that, there are smattering of topics related to the ROI of refactoring, the economics of code change and new strategies for large method and large class decomposition.

On Monday, April 4th, I'll be teaching my first course on this material in Chicago.  If you'd like to attend, there's more information here.

 

 

Data-Rich Development

Every once in a while, I get upset about something that happens in software development.  Sometimes I simmer, sometimes I smolder, but eventually, I do pipe up about it.  The thing that's been bothering me for a while is the fact that agile really threw the baby out with the bathwater about 10 years ago.  At that point in time, we we had many people with deep design knowledge in the industry.  Hundreds of books had been written about the mechanics of object-oriented design, and structured design. Although this knowledge was not pervasive, you had the sense that if you walked into a room of people who cared about software development, they'd be familiar with many of the design principles, patterns, and concepts that were being thrown around then.   

I'm not sure that has changed.  People who care, still dig deep and learn.  The thing that did happen, though is a de-emphasis of software design over the last ten years.  I think that there are a couple of reasons.  One was maturity.  There was a a lot of material out there 10 years ago, and it was excellent guidance.  Maybe we'd just discovered the foundation of design and we've all moved on to other things.   Another was a well-deserved re-emphasis on the people part of our work.  Nowadays, the hot topic is: how to best get people to work with each other to deliver software.  The last reason to mention is TDD/BDD.  With Test-Driven Development and Behavior-Driven-Development, we moved much of our design discussion into the realm of micro-process: you take these little steps and good design emerges. That tends to be true, but no one can deny that it requires guidance and you can only really guide the evolution of  your code when you have good design chops.

So, where are we now?  I think we're at the cusp of something very interesting in the software design space, and it involves looking at things a bit differently.  Let me start with a question.  The last time you saw a blog or an article about design, did it just give you a single snippet of code outlining an idea?  Chances are, the answer is yes.  An article about refactoring might give you a before and after shot.  But, do you ever see anything like this in articles about software design?

This graph shows the history of a file in a project in terms of complexity.  You can see that the complexity of the file has grown over time, but there are dips, and those dips likely indicate complexity-reducing refactorings that have happened over the life of the project.

Okay, how about this diagram?  It shows the number of commits for each file in a project in order of increasing number of commits.  As you can see there many files that have only a few commits and a few that have an incredible number. 

Remember the Open/Closed Principle?  The notion that in a good design, we have many abstractions that don't change very often.  Well, guess what?  We can figure out whether it really happens on a project, and how often.  All it takes is a little SCM mining. 

Some of you reading this might be thinking "Oh, no! Metrics."  I understand.  Metrics do have a well-deserved bad rap.  There is nothing worse than managing by a code metric. It throws away too much information and there are always unintended consequences.  This isn't really about that, though.  It's about taking the data that we have at hand in our development work and really using it.  If we are making a decision about whether to refractor a piece of code, we should be able to see its churn and complexity trends, and tie them back to events that happened over time, and the actual features which triggered the work.  Right now, it seems that we often look at our decisions through the pinhole of the present, ignoring what we can learn from our code's past. 

At the time I'm writing this, there are many people who have been playing with these ideas for a while. Steve Yegge and many others at Google have been doing quite a bit of code mining work.  Keith Braithwaite has been exploring how TDD affects the complexity of code. Joshua Kerievsky of Industrial Logic has, more than anyone else, pushed the direction of these ideas. His dream is to have IDEs with historical information, information mined from production logs and quite a few other things at our fingertips.  Jason Gorman, Tim Ottinger and Greg Wilson share an interest in gaining a deeper empirical understanding of software development through this kind of work, and Chad Fowler, Corey Haines (blog) and I are brainstorming ideas and actively developing tools to facilitate work in this area.  Currently, we're working on a Ruby gem called 'Turbulence' which plots churn and complexity for Ruby projects. Brian Foote of 'Big Ball of Mud' fame looks on and makes sage observations about the shape of software.

Interesting times.