Marcus Zarra’s NSConference talk today - about how reinventing the wheel is ok, maybe even to be encouraged - was thought provoking. In fact, I think it was downright provocative. Which is great :)

I recognise a lot of the sentiment behind what he was saying, and have undoubtedly had that same urge to reinvent on many occasions.

I generally feel that it’s useful to understand at least one level below the one at which you are working. If you’re using Objective C, understand C. If you’re using C, understand assembler. If you’re using an open source framework, understand how it works or the technology on which it is implemented.

And yes, it’s hard to really understand a coding problem until you’ve tackled it yourself.

Also it’s quite true that generic code is never going to be as optimal as a bespoke solution.

However…

When you use an open source library, you are typically using code that has shipped in existing products. In multiple existing products. Products that have provided the code with hours/days/months of testing with real world data. Is that worth something? Hell yes.

There is code out there which is broken, unused, or just plain rubbish. Undeniable. That’s an argument for choosing carefully, it’s not an argument for not using other people’s code.

The fact that it’s hard to understand a problem until you’ve tackled it yourself makes it tempting to rewrite. Very tempting. I have ripped out and rewritten plenty of other people’s code in my time. Many’s the time I have simplified “unnecessarily complicated code”: “what an idiot this guy is, look at all this crazy shit he’s doing…”.

That same fact is also why you really shouldn’t, most of the time. Unless you have the luxury of enough hours to rewrite the same thing more than once on the same project, or the luxury of doing the same thing repeatedly on each project. When you rewrite, you will fuck up. The fuck up rate will probably never get to zero, but it will almost certainly only reach an acceptable level after two or more attempts.

It’s uncanny how often that “weird shit” that you ripped out near the beginning makes a quiet return (with the variable names changed to protect the innocent), when the subtlety of your understanding of the problem finally catches up with that of the person who wrote the original version.

When we use someone else’s code, the trade off we’re making is to exchange that deeper understanding that we would have gained by doing it ourselves for the luxury of not having to go down all the blind alleys first.

When it comes to the risk that comes with using someone else’s code, I agree with Marcus that it’s always good to understand it.

But if you’re selling your client on the idea of doing an upfront rewrite of something now on the basis that there’s a 20% chance that they might conceivably need to do it later… well, that’s nice work if you can get it, but 80% of the time it’s stuff that they didn’t need to pay for. Sure the cost of that 20% scenario might be much worse than up-front rewrite, but there are other ways to mitigate against that worst case.

Marcus seemed to be describing a situation where you’re basically doing similar projects again and again. In that case I can also see the attraction of starting from scratch each time. Like a master craftsperson essentially making the same chair over and over again, that zen-like quest for perfection is seductive.

Most of us don’t live in that world though.

I’m not saying that we write code once and let it ossify for ever more, or that we grab the first thing off Github that looks vaguely ok and never question it again. There’s a hell of a lot of room in between that and what Marcus seemed to be advocating though.

Jamie posted a reply to Mattt about an article Mattt wrote on stewardship of open source code.

I totally agree with Jamie here. Yes, a well maintained and documented library should be the ultimate goal, and if Mattt’s article had been entitled “How To Create A Successful Open Source Project”, or words to that effect, it would be fine.

But the tone did seem to me to suggest that you shouldn’t put code up there unless you’re prepared to go all the way to full-on well supported open source project, and that is frankly ridiculous (and a little pompous).

I have a lot of source code out there on github. I know that a lot of it is out of date, or not as well packaged and explained as it ought to be, and I sincerely regret that. However, I make no claims for it being in anything other than that state.

Most of my public source is code that has been created as a by-product of past or ongoing work. I would love to polish and refine it into a more drop-in form, but life keeps getting in the way.

Faced with the options of putting it out there in the hope that it will help someone (and perhaps inspire someone to help with it), or removing it until I have the time to polish each library to perfection, I think that there is only one sensible choice.

I would encourage anyone who has even the slightest desire to share in the open source community to do so.

Put aside ego, hubris, and insecurity, and put your code up there.

Be open about the fact that it has flaws, invite constructive criticism, and by all means aspire to the perfection that Mattt is talking about. In the meantime, relax for goodness sake!

There’s a new beta of Neu out on the beta software page.

This one is 2.0, which sounds like an exciting change, but actually at this point it’s a small evolutionary step and not that different from 1.3b4. There are quite a few under-the-hood changes still in the works, but they aren’t quite ready for prime time, so haven’t made it yet.

However, what has changed is that support for 10.6 has been removed. It’s always a tricky decision to drop support for an old system, but as a small developer it is really quite necessary to keep the number of systems that you’re testing with to a manageable minimum. With 10.9 just around the corner, and 10.6 now pretty old, the time had come for a change. Rest assured that if you need to stick with 10.6, the old releases of Neu should continue to work, but moving forward, it’s 10.7+ only.

The one other thing that’s changed is that Finder menu support has been temporarily disabled if you are running 10.9 (Mavericks). It turns out that some changes in the Finder under 10.9 have broken Neu’s menu hack, and this can result in the Finder crashing continuously whilst Neu is running. We definitely don’t want that happening, so the best plan in the meantime seemed to be to simply disable it until I can get it all playing nicely once again. Watch this space on that front…

Ambientweet 1.2 is out!

Strictly speaking I’m treating Ambientweet as in “maintenance mode” now, as it’s not really being actively developed.

However, Twitter’s recent turning off of their old 1.0 API broke Ambientweet, and I wanted to at least get it working again, hence the release of 1.2.

By all means report any bugs that you find still lurking within this version, and I’ll endeavour to fix them…

Some interesting coding guidelines from Richard Buckle (@RichardBuckle).

I’ve not read through the whole document yet, but what I’ve read makes a lot of sense.

Like all these things, much of the value comes not with slavish obedience, but with the thought that is provoked. Introspection about what we do as coders, and how we can do it better, is essential.

(oh, and thanks, Richard, for the ECLogging namecheck…)

Update: I’ve read em all now, and I can’t find anything to disagree with.