Back in the days when I was still smoking weed, I was rolling a joint and noticed my dog was looking at me in an investigative way. So I took a small bud of weed and let her smell it. She sniffed, and then she shook her snout against my hand making me drop it. Immediately she took it, and ran away a couple of metres. I tried to get it back, but she turned her body keeping me away from it while she ate it. During the rest of the evening, she kept lying in the sofa, upside down, paws up in the air. Eventually she got up and ate her bowl completely empty, then got back into the sofa. It's the funniest thing I ever saw her do. I don't know if it's normal or not. Do dogs like weed? Mine did for sure.

Just what the world needs: more weaponry. Don't these people have anything better to do with their lives than inventing new murder equipment?

So infertile people don't deserve to get married? People who willingly choose not to have children don't deserve to get married? I'm hearing your religious excuse machine already spinning up from here.

Erm.. those people?

The study was made in cooperation with the University of Transylvania.

No that's just one of the problems. The rabbit hole goes much deeper than that. Also, even with such deep inspections, the public interface is, well, public, so you cannot optimise it away. At best you can use tools to hint at such cases. After that you can modify the API (and the API documentation).

Well, it was an embedded company. This was the first project of such a large scale, and they lacked experience. The manager had worked there for 30 years, and had an electrical engineering background. So it wasn't an ideal situation: he was certainly competent and he could definitely write code, but lacked the experience in software engineering, like how to keep a large software base maintainable. So for example, he had this obsession with not changing code once it was tested. Since all these modules were tested, he was very nervous about changing it. What he failed to see, though, was that more modules were going to be added, and without a clean definition of how this data was to be represented, constant conversions were going to be needed (plus some other things I'm not going into now). Also, automated testing was not a practice there. This is one of the things I worked on introducing at the company, although frankly it was much to late to add it to the existing project. So he was never going to allow to merge the changes back in, because it "broke" tested code.

And I'm not saying I'm all for changing tested code - not at all , but in some circumstances, spending some effort up front can save you a lot of time later on. And I'm sure it would have.

Also, I'm quite confident of my skills. Sure I can still improve, but I surely developed a reputation of writing code that "just works". After 4 years, only a small fraction of the bugs were assigned to me, mostly they were located in parts I didn't write. Mastering the programming language is important, but there are lots of other very important things that matter. You just need a lot of discipline, checking all input, immediately failing when something goes wrong (not letting bad data trickle down the code), clean separations, higher order programming, trying to minimise the interface between modules etc... The list is so large, it becomes more of an intuition.

I hope this clarifies it a bit, I surely wasn't expecting the Spanish Inquisition.

OK, to clarify: I wasn't doing that on live code, it was a special experimental branch. My manager didn't want me to spend more time on it. But I was allowed to experiment, and then turn to the manager, present it and ask his input. Just stopping on my assignments and doing a weeks long rewrite needs approval of course, but fooling around a bit while you're stuck with another problem, was no problem. Is it really so abnormal to work that way?

Well, no, I got paid so if they don't want me to do that, I don't do it. Simple as that. But I did write a mail saying what parts of the code were going to continue to be bug-prone if if didn't get cleaned out. When I was packing, I found it back and I was completely spot on. One of the parts I mentioned needed a small change at that time, and it was already taking an engineer two weeks to implement it, constantly introducing new bugs. In hindsight my manager said I was correct. Nobody wanted to see me go, I rescued the project on more than one occasion. It was on an embedded platform so when performance was degrading I wrote a tool to find out where it was spending most of its time. Four months later we shipped a new version with more features and a lot of performance improvement, faster than it ever was. It's been in use ever since.

I also left the company without slamming doors, it was not directly related with that project but it did cause some changes: managers were now taking on smaller projects, with less R&D investments and less risks. I can understand their reasoning, but that didn't keep me motivated. That's all.

I do think it matters. Yes, a compiler can throw out dead code, but not in all cases. E.g. if you have an enum where some values aren't used, and you then call a function if a variable has that unused value, how is the compiler going to find out? It's not only functions, there could be unused tests in code etc. All this clogs up the code and can make reading the code a living hell. It can turn an elegant part into a mess. Not mentioning the time wasted of developers trying to find out what a function does, only to discover it's not used. The article doesn't deal with the results in terms of code size or performance, but I'm very interested to find out.

Anyway: you can either have clean code or maintainable code, but not both at once in my experience.