It’s sometimes possible to forget when reading all of the posts here about travel, diabetes, triathlon, and photography that they’re just a small part of my life. I have a job to which I devote a whole lot more time. I don’t talk about it much because (a) discussing what I’m working on putting into the Image Processing Toolbox isn’t appropriate or allowed, and even if it were (b) talking shop probably isn’t that interesting to most of the people here. But—believe it or not—the majority of traffic to my site lands on the pages that are technical, so I don’t feel so bad about posting the random “fodder for techno-weenies” post. (It’s a term of endearment, I promise! :^)
This is another one of those posts. Every year between Christmas and New Years Day, I try to use the quiet week to get stuff done and tie up loose ends. Last year, I cleared out a bunch of notes. This year, I’m looking at presentations and slides from the QCon SF 2011 conference (wrap-up). Its focus on software architecture and project management is about 75% of my job, so many of the presentations seemed tailor-made for me. Here’s some of what I learned.
Erik Doernenburg. “Software Quality: You Know It When You See It” has a really good slide deck that got me thinking about some projects I might want to set up. It’s full of practical, usable suggestions:
- View the code at the 1,000 view, rather than ground-level or 30,000 feet.
- Look at the test-to-code ratio, not just code coverage.
- Graph the change of metrics between versions and revisions, compare across different parts of the code, and look at them relative to industry standards.
- Measure the “toxicity” of code by rolling up various quality metrics about a bunch of modules into stacked bar charts.
We should pose these questions during design and code reviews:
- Is the software/change of value to its users?
- How appropriate is the design?
- How easy is the code/design to understand and extend?
- How maintainable is the software?
Joshua Kerievsky. “Refactoring to Patterns” — some notes:
- Refactoring is like algebra’s equivalence-preserving manipulations. “Design patterns are the word problems of the programming world; refactoring is its algebra.”
- Understanding the refactoring thought process is more important than remembering individual techniques or tool support.
- Code smells have multiple refactoring options and often benefit from composite refactorings.
- Look for automatable refactorings first. Consider changing the client of smelly code before the smelly code itself.
Guilherme Silveira. “How To Stop Writing Next Year’s Unsustainable Piece Of Code” was pithy and thought-provoking.
- There is no value for architecture or design without implementation. That’s just interpretation of the software.
- “New language. New mindset. new idiomatic usage. Same mistakes.”
- Complexity and composition are natural and good, but if they’re invisible, they’re evil.
- Start with a mess and refactor right away. Starting “right” is hard (and misguided thinking). Refactor for better, not just prettier.
- Make complexity easier to understand and see.
- Hiding complexity in concision hurts testability, since no one knows the complexity is there. Furthermore, if it’s hard to test, it’s also hard to use correctly.
- “Model rules. Do not model models.”
Michael Feathers. “Software Naturalism: Embracing The Real Behind The Ideal” is a presentation that I would like to see/hear, since the slides seemed full of information but weren’t self-explanatory. Here are two things I could glean: 80% of software defects in large projects were in 20% of the files. In general, the more churn in a file, the more complex it tends to be.
Panel: “Objects on Trial” was perhaps the most unusual presentation, since it was a mock-trial. I use objects all the time . . . some of them are good . . . some demonstrably so. Even so, I never latched onto the idea of object-oriented (OO) design versus objects as types. The four panelists, in one way or another, basically said, “That’s the problem.”
One of the panelists drew an extended analogy between the space program and OO. The space shuttle (which we all love) was fixated on reuse but basically was a waste of heavy lifting; people don’t reuse the right stuff. In software, object reuse is largely accomplished by cut-and-paste copying of boilerplate code that does close to what you want. Of course, the panelist acknowledged that we do reuse the ideas in OO via design patterns, and no one seems to have much of a problem with that. Ironically, having a rich pattern language means that software engineers are in a better place than ever before to use objects correctly.
A key problem with our approach to objects is that we’ve failed (generally in software engineering) to handle complexity well, which was supposed to be the point of OO design. A conflation of beauty and OO design makes things worse. Internally, software is ugly, and beauty shouldn’t be a goal. Making a fetish of beauty makes code inflexible because people don’t want to extend the beautiful thing that works.
For other panelists, objects weren’t the problem at all. For them it’s static typing in “OO languages,” such as C++, Java, and C#. We’re at a place now where all of the good things about OO have been lost in an attempt to make OO languages as fast as C. This runs counter to the goal of having “ordinary,” understandable code. Generic programming using strongly typed (possibly template heavy) languages just makes everything complicated.
For me, it’s moot. C++ is what I use, and I don’t have a large proprietary object system that I can tap into for reuse. I’m in the camp that uses C++ objects to generate new types for data hiding and aggregation, as well as (to a lesser extent) reuse. But some of these types are generic, template classes that are hard to understand. I plead “no contest.”