jmostert2

First of all, IANAL and I have no real-world experience with your scenario either. Below is all armchair reasoning. That said, my chair is pretty comfortable and I reason a lot from it.

Using patented technology without a license from the patent holder is illegal. On the other hand, you can't be sued unless people know you're doing something wrong. In-house technology that runs afoul of patents is therefore pretty safe, provided all the employees can be trusted... The moment you start exporting your technology, though, you're in trouble.

Making software open source does unfortunately not "avoid the hassle of patents". Whether your software is proprietary or open source, it can't use patents without permission. Conversely, you can hold patents on software distributed as open source -- although there would be precious little point to that, but maybe someone with an original licensing idea can correct me on that. In any case, a lot of licenses (most prominently the GPL) simply forbid this construction: if you release the software as "open", you implicitly grant everyone a license to use whatever patented technology you've included. Obviously, this can only apply to your own patents or patents you're allowed to re-license.

So: if you don't intend to publicize and you're worried about patents -- don't publicize. Conversely, if you do intend to go public, invest in good legal help first that specializes in IP. Checking your product for patents is hard, as is drawing up strategies for dealing with claimants. Nothing would be more disheartening than pouring a lot of effort in a product you will not be able to ship because a third party asks an exorbitant price for their patent use or refuses to license outright. They might buy your product from you, but that doesn't give you a startup.

This is not a question of "manning up", really (it's not like you can study real hard and then you've worked it out), it's one of economics. I have no idea how expensive the patenting business is, but TANSTAAFL in any case.

Judging a blog post by its title alone is hardly fair. Raymond clearly explains what it's about in the post itself. No pretenses about full generality are being made. "Some caches confuse some memory leak detection tools" may be more accurate, but it's hardly catchy.

Also, analysis is only as good as what you know to analyse. Calling a memory analysis "naive" because it bases itself only on the system allocation/deallocation routines (which are, after all, the logical starting point for any such analysis) is just silly. Sure, the analyzer could have been extended to know about BSTR caching, but there's obviously no limit to the amount of cleverness you need to build in to properly analyze everything this way. Any sufficiently advanced cache is indistinguishable from a memory leak, that's sort of the point.

The Dutch government is batting 10 for 10 when it comes to pushing through legislation that mocks the idea of privacy openly. Another stellar idea they had: gather fingerprints for every single person in the country and store them in a central database. I know it sounds like a bad joke, but it's not (http://www.dutchnews.nl/news/archives/2009/09/fingerprints_i...). The law was passed without any problem, and only now privacy groups are fighting back.

It's scary when your government is so obviously looking out for itself, rather than you, and failing to even see the difference. After all, what's good for the government is good for the people, eh?

But "experienced" is another one of those glowing words (like "smart") that emphasizes you knew your way around in the past. This is an external marker, something other people judge you by and you can advertise with. When you have to solve actual problems, it's no good to think of yourself as smart and experienced, because that will only frustrate you if your amazing talents don't immediately suggest a solution. Taking yourself out of the equation and treating each problem by its own merits rather than your own merits is what's required, and that's the point of the "lazy" and "dumb" epithets: they're a deliberate kick to your ego, something programmers can usually use less of. Your talents can take care of themselves.

"Lazy" I get, but when he says "dumb" I think "humble" conveys the idea better. You shouldn't be "too smart", but that's not the same thing as being dumb. Letting go of preconceived notions to get to the root of a problem may involve "playing dumb", but that's still not the same thing.

Still, "dumb" sounds less chest-beating than "humble" (ironically enough) so if you think you're not humble enough about being humble, by all means start calling yourself dumb instead. :-)

If the code is really intricate, I refactor it to understand how it works (and how it ought to work, which can be an important way of spotting bugs).

But even though refactoring is supposed to be perfectly mechanical and "harmless" (especially when supported with unit tests) I'll usually throw away my refactoring, because the risk of breaking the existing code is just too high. It depends on how invasive the new feature is -- if I'm going to have to change a lot to get it done anyway, I might as well incorporate the refactorings. But if the change literally is finding the right position to add a single line of code, no way I'm going to change things once I find it.

When it's clear that adding even simple features takes an extraordinary amount of time because the code is that hard to understand and maintain, getting/making time for proper refactoring is easier, but it's worthwhile even as a way of creating a mental model.

I've never tried unit tests to figure out the semantics of existing code, though, even if it seems obvious in retrospect. I think the code base would have to become very complicated indeed before I go into full scientist mode and construct hypotheses on the semantics and verify them with unit tests. If the code is a tangled mess, it could also be tough to extract the proper bits to test on and/or set up a test environment complete enough for that.