Mac OS 10.6
The announcement that wasn’t on Monday was that 10.6 is going to be coming out sometime next year. The reason they didn’t make a major announcement about it was that it isn’t going to actually have any new features. Apple is planning on going back over what they currently have and consolidating and pruning and improving. (The name is very clever, since it will basically have the same customer facing feature set as Leopard (aka 10.5) they are calling it Snow Leopard.)
For the non programmers who read my meow posts, cleaning up old code is absolutely critical. There are so many instances where the second time you write something it is about a million times better than the first. So doing an entire release cycle with no new user facing features is just about the best thing you can do with an OS.
My guess is that 10.6 will be by far and away the best OS Apple has ever made if they are able to stick to their plan. Of course, there will be some new features. Some API internals that will make the life of developers better, but hopefully they will be able to keep those to the minimum needed to really give the developers time to work on improving the existing code base. It is simply a focus on quality that you normally don’t see in software, where the constant drumbeat is for new and flashier features.
It will be interesting to see how this plays out, if they are able to not shove a bunch of extra features in it, and how much they will charge for something that, while wildly improved over the previous version, doesn’t show any new features to the end user.
June 11th, 2008 at 10:10
while wildly improved over the previous version, doesn’t show any new features to the end user.
I’ve been wondering about that myself. It seems like a hard sell, unless application developers can make a case that the users need it to use the new programs. (For example, OmniGraffle 5.x, which can read Visio binary files, is 10.5 only, and that’s what pushed me to finally install Leopard, even though I’d bought it in January.)
June 11th, 2008 at 10:36
Cleaning up old code is also a huge risk. Remember the story about the guy from Apple who wanted to clean up the Font/DA mover? The mactech.com web page isn’t responding right now, so the Google cache URL is:
http://209.85.173.104/search?q=cache:TOdcpUFVFZIJ:www.mactech.com/articles/develop/issue_25/veteran.html+font+da+rewrite&hl=en&ct=clnk&cd=5&gl=us&client=firefox-a
The story is:
——————————————————————-
UGLY, YET EVOLVED
Once upon a time, I was asked to fix a couple of bugs in Font/DA Mover and make it work with TrueType fonts, as an interim solution before System 7. The program was so disgusting to me that I just had to go in and clean it up. Move this here, change these names, document some pieces, take out the redundant code, modularize some pieces — ah, how aesthetically pleasing. Oops . . . I just introduced a couple of bugs while I was “improving” the code. It felt like progress, but actually it was just motion. You know, like company reorgs.
What to do? Don’t “improve” code, unless it’s never been debugged. Any fully debugged code, no matter how shoddily written, is superior to newly written code, no matter how pristine. It went against my grain, but the right answer was to leave it gross. That heavily used Font/DA Mover code had thousands of hours of value in it, with literally millions of testers, that were all lost when I rewrote it. Rewriting it took time that I wanted to spend on something more valuable, like fixing the last few remaining bugs — and then getting outside and windsurfing! Once I rewrote the code, it was like a new program, and thus needed a full development/testing/debugging cycle. I backed off to an earlier “skanky” version and just debugged that.
Super-value rule: Never rewrite something that’s been fully tested. It may be ugly, but evolution is on its side.
——————————————————————-
I don’t think the rule is “never rewrite”, but it certainly has to be approached with a great deal of trepidation. When I think of the embedded (and partly forgotten) wisdom in the source code I deal with, the idea of rewriting smacks of craziness.
-alain
June 11th, 2008 at 11:27
Risk of refactoring:
“If it ain’t broke, don’t fix it” is certainly a good rule, but cleaning up within the realm of the existing codebase can often gain huge results. Especially if it is broke. I have had numerous instances where refactoring to combine common elements saved many debugging hours later.
In one case all of the “bug fixes” that had been learned over the years, had been implemented as code duplication, rather than delegation or some other cleaner method of existing code modification. By building a good testing infrastructure for each of the duplicated classes we were able to avoid major regressions while combining the code into a uniform structure with the changes delegated out where appropriate. The truth was that the code had become so complicated that no one was able to figure out what was going wrong when it gave the wrong results. A few new bugs were introduced, but the time and effort in fixing those was considerably less that fixing the previous bugs had been. Also, during the refactoring a number of extant, previously unknown bugs were found and eliminated. (Unit testing!! They never had proper testing frameworks for it before.)
I think I generally agree with the author of that story, especially “rewrite”. That is a scary word. Also, in my case the code was certainly not “fully debugged”. But relying on forgotten embedded cruft is also pretty scary. There has to be a balance between leaving it as it is and moving forward. I am partial to the agile theory: only write what you need to, but don’t be afraid to change existing code if you need to. In the case of the story you give, it sounds like the changes he was making to the old code extended beyond the specifics of what he was working in. I wonder if the “clean up” he did was restricted to the features that he was working on, if it would have come out differently?
You certainly need to understand the risks of cleaning up old code, but being unwilling to do so also carries risk.
June 12th, 2008 at 09:25
Sure, relying on forgotten cruft is scary, but I think it’s also a fact of life with any large code base. Legacy code often doesn’t have suites of unit tests, good comments or design documents, but it is still in use. It doesn’t make the code “bad”, though it often doesn’t appeal to our aesthetics. I think that cleaning up old code is often more dangerous than leaving it alone, assuming there are no active problems from the code.
-alain
June 12th, 2008 at 12:58
Alain,
I think we are agreeing. I am answering you again because I am interested in understanding where you lie on the fix code, or leave it alone spectrum. For me, the moment to go into old code is the moment when it isn’t doing what you need it to any more. This can be for a number of reasons. In my case it tends to be one of three things: new feature requirement, newly discovered defects, or scaling failures (that is to say performance issues). If it ain’t broke, don’t fix it, but when it is broken… what to do? Up to here I think we agree.
Where we might differ, is what to do in those cases. My experience has been that when one of these issues forces you to go back into old code, you are better off keeping the change as small as possible, but depending on the code, piling more hacks onto a pile of existing hacks might just bring the whole thing down. Referring back to the agile methods I mentioned earlier, this is the competition between “Working software is delivered frequently” meaning just make the smallest change you can to make it work, and “Continuous attention to technical excellence and good design” meaning don’t leave broken code in there.
Doing contract work, I get a constant introduction to new large legacy code-bases that need modification. One of the fun parts of that is figuring out where that balance is in each new project. (The bad part is finding that the time frame is so short and the code is so broken that the best you can do is write a test case for each functional spec and tweak until they all work. Ugh. That was NOT fun. But even in that case, I was able to do some clean up, when I discovered that the reason some parts weren’t working was cut and paste errors. Nice easy class extraction, covered by my new tests.) I’m guessing that our pain points on refactoring versus small modifications are different. Also, when I do “clean up” code, I really try to keep the changes as small as possible, and leave an easy fall out should the refactor fail. (e.g. in the class extraction above, the original functions were left in as deprecated, and comments at the replaced function calls noted the changes in case I missed some hidden dependency.) How do you deal with that decision? Just never refactor? Or only refactor in the smallest most obvious cases?
June 12th, 2008 at 13:01
also… my assumption with “cleaning up” the existing code base for apple would be that they are fixing bugs, and improving performance, creating a more stable base for future development. Not that they are just making the code prettier.
June 12th, 2008 at 13:37
Testing is a good, good thing. I can’t impress that upon people enough. I swear, I’m going to buy a copy of _The Pragmatic Programmer_ for the folks I’m working with.
On the subject of changing code, I was given a bit of advice the other day. It was more or less, “Any time code is touched, there’s a risk that something will break, even if you’re only changing a comment!” It was primarily an argument for structuring the code so that you can add functionality without having to rebuild the system (make it data driven or user configurable), but also a statement in support of testing.
June 13th, 2008 at 11:04
Josh, I think we probably agree, or we’re at least very close.
I guess I’m sensitive to the topic, because there are a lot of people in the world (not you) who don’t understand the complexity of cleaning up code in a legacy code base.
I’m with you on testing. I get an email at 8:00 every morning that tells me how my nightly tests did. (They take hours to run, so they’re not continuous tests.) It saves my ass all the time, even though my testing is not as complete as I would like.
-alain
June 17th, 2008 at 16:20
I guess I’m sensitive to the topic, because there are a lot of people in the world (not you) who don’t understand the complexity of cleaning up code in a legacy code base.
Interesting. I seem to encounter the opposite problem. “Oh I can’t touch that code, someone else wrote it, I don’t know how it works, I will break it.” OTOH, that might not be a healthy respect for the problems of dealing with legacy code, and more just laziness. But I can see the opposite being a real problem. (I have had to re-fix bugs in the past because people “cleaned up” the code.)