I’m a big fan of Michael Feathers’s book Working Effectively With Legacy Code, and now and then I reread it because there’s always something to refresh or remind me.
Right now I’m looking at the “Wrap Method (67)” technique. It’s really simple. I’m just restating it here.
More
If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.
Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)
One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.
Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.
Sure. There’s nothing wrong with that if it makes you feel better.
The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.
Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…
In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.
I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.
So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?
Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.
The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.
I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.
So I spent a lot of the weekend refactoring my Healthy Homes database system. (I know, what a party animal.) And after getting some solid work checked in, I realized it was definitely time to do a major refactoring of the Data Access Layer (DAL) code.
I’m in the midst of an email conversation with a pretty well-known turnaround CEO adviser, the kind of person who can Make Your Company Not Suck. He’s way beyond me in terms of influence and reach, and he consults enterprise-wide for way bigger outfits, but for some reason he ended up asking me why so many projects still get in trouble even though all kinds of training and certification are available these days.
This is about what I wrote back.
A year and a half ago, this really interesting scientific programming project more or less dropped into my lap.
The original code was written by a physicist–let’s call him Jim–who wasn’t a professional programmer but actually did an okay job writing and maintaining this Visual Basic Classic (pre-.NET) code for several years. “As a programmer,” someone might say in a gently mocking tone, “Jim’s quite a good physicist.”
So it’s cool. The important thing was to solve the scientific problem, and that it did. When I picked up the code with a mandate to get it working on a .NET platform and add a few features, though, I found it fairly hard to follow. A lot of the operations really needed to be event-driven but simply weren’t. There were a lot of modal dialogs and there were Windows forms with a ton of overlapping controls that got shown and hidden at various steps in the process.
So it was slow going, getting the thing to build and actually run on .NET. But the thing that saved my sanity in so doing was asking one simple question over and over again:
Does this code get used at all?
In many cases, the most difficult code was unmaintainable because nobody had to maintain it anyway. I consulted with the client, was told that the code implemented a feature that nobody used or even knew about, and simply deleted it. (After! Of course! Having all the originals under version control!)
There was a mishap or two in that regard, such as code invoked by menu options that seemed to be permanently disabled, but still. I could go back to version control (Subversion in this case), pull the original code back into Visual Studio, and massage it to get it to work.
But the massive reduction in workload caused by not having to work on 30% of the system at all more than made up for the few little problems. I’m pretty sure that the most effective development optimization of all, when working on legacy code, is simply cutting out the code that is never invoked or nobody cares about.
Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?
Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.
So this week I’m seeing on the KanBan:
This is oversimplified and (only very slightly) dramatized, but you see the overlap and the potential for confusion. These story cards are blocking a ton of other work that needs to be done in the next couple of weeks. And they’ve been claimed by different developers!
If you’re a big Critical Results fan–and who isn’t?–you may have missed my regular blog updates for the last week and a half. Let me tell you what’s going on.
Recently I wrote about some of the Really Big Cool Commercial Things people tried to do on the Internet when it was still kind of a fad. These Big Things tended not to work out either because they didn’t make sense to begin with, or because their perpetrators could never settle for something that actually worked and delivered value.
I think (and said then) that this is probably because people often enter into business for reasons other than doing stuff that works and delivers value. If, on the other hand, you *cough* do stuff that works and delivers value it’s a lot more likely your business will do well. Notably, it doesn’t have to have an amazing idea behind it.
My favorite example of this is those nifty little PC-based cash registers. I’m a bit out of date on who has what these days, but back in the early and middle 1990s it seemed like one out of four mall stores had something from Systems for Today’s Retailer, which went by STR most of the time when I worked there.
STR started a little like this. Scott and Chuck what I call a dumb idea: to mimic those $10,000 intelligent cash registers that know how much everything costs, calculate discounts, print time cards, keep inventory up to date, and send sales data back to the corporate offices. Except they would do it for around $3,000 on an industry-standard PC.
I’m sorry, there just isn’t very much to it.
It hit big. Everyone wanted this. They made their first sale to a small chain of jewelry stores headquartered in California. Then there were a couple of local Ohio customers. A place that sold swimming pool supplies, stuff like that. There was a chain of pet supply stores. And a nascent chain of computer superstores. None of these were gigantic wins, but they were mostly solid customers who paid a fair price for a good product.
Hey, there were a lot of problems with the software. By the time I showed up as the fifth employee, Scott’s office contained a clear box of 5.25″ floppy diskettes, generally three for the uniquely copied source code for each client’s custom applications. “Source control” was pulling things out of the box and putting them back.
What we considered the “base” application was about 160,000 lines of Clipper code, largely cut and paste from previous versions. In fact, one of my first really big refactorings involved merging eleven slightly different versions of the main item entry function into one, with just a little branching to distinguish the eleven kinds of transactions. It wasn’t the best code base to work with.
The key thing Scott and Chuck did, and this was seriously brilliant, was to figure out what people wanted to pay money for and making it work well enough to use. (Well, that and hiring me.) In a few years, STR had become fairly stable and rather profitable. We had matching 401(k) plans and good health insurance. It was a good place to work, and the software itself got quite a bit better as we improved our code and project management practices.
I started working with those guys almost twenty years ago now, and I still keep thinking… wow, it’s just a cash register with a regular computer in it. That’s all.
One is fun to think about. The other is a lot of hard work.
And what do you know, tonight begins Startup Weekend Cleveland. In about five hours, I’m going to join about seventy other business and technical people to talk about ideas, pick a subset that the group will develop into products, and personally contribute to one of those. Which ones will be most successful? I’m betting on the ideas that make people say “I need that!” not “Oh cool!” In other words, the stuff that works and creates value.
It happens a lot, especially when working on legacy code, that you can’t figure out a “business logic” algorithm that isn’t already well documented. Sure, it’s in the code, but so are a million other things, and you can’t eyeball the part that does all the calculation. The client is asking for a change or a fix and you’re not sure where to start.
That’s when I think you can do three things at once: improve the overall structure, impose some unit testing, and solve the problem you were asked to. Refactoring does all of these.More