Comment by lighthawk | Hacker News Reader

Comment by lighthawk | Hacker News Reader

“People who implement new and improved interfaces always seem to get that wrong.”

Linus is completely right on this. I have seen this over and over again where developers, creative and problem solving as they are, attack things with their limited experience and knowledge and fail to understand things fully before heading in like a bull.

There is a time and place for that sort of behavior, though. Linus wrote Linux with that same mentality. Sure, he was exponentially smarter and more able. :) But, that was the time for starting fresh with a cavalier attitude. However, if you try to contribute something like this to Linux today, as mature and stable as it is, and majorly screw it up, yes, you are wrong and expect your ass to get chewed.

I just worry for Linux's sake who, if anyone, will be able to replace Linus if he were to choose to retire or were whisked away by aliens (I won't say die). Some related discussions about that:

http://ubuntuforums.org/archive/index.php/t-424721.html

https://www.reddit.com/r/linux/comments/2fnnva/what_would_ha...

> attack things with their limited experience and knowledge and fail to understand things fully before heading in

Over the years I gradually came to this core truth of programming: solving problems is easy, it's understanding what the problem is that's hard.

Kinda sorta similar to "it's not about coding, it's about modelling": http://www.chris-granger.com/2015/01/26/coding-is-not-the-ne...

Also, understanding which problems are worth solving is hard as well. That's where the "charge in like a bull" approach can be handy: a number of problems are worth solving that people shy away from, either because they're viewed as too inconsequential or because they're viewed as too difficult, and they don't get resources devoted to them until somebody has paved the way with a quick & dirty solution.

I found a quote recently by G.K. Chesterton about this that I really like.

"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."[1]

[1] http://www.chesterton.org/taking-a-fence-down/

Sounds like a great way to start a fight with a monkey in a cage.

Nobody builds a fence for no reason. Keep in mind that he isn't implying that it was a good reason, just that there's a reason why it's there and you should understand that reason before taking it down.

I can't get to completely agree with it, but the completely opposite idea that you should just not care is stupid.

That used a lot of words to say very little.

It appears to be less true now than in days past, but humans are -first and foremost- storytellers. we like to tell stories, we like to listen to stories, and we -often- better remember lessons imparted in the form of a story.

Moreover, if you're trying to alter someone's opinion about the truth of a matter, you almost always need bolster your core argument with supplemental material. You often don't know much about your listener's background, you probably don't know what motivates him, and he may very well be opposed to your core argument for entirely unreasonable reasons. It's often best to surround your core argument with a large, somewhat varied structure, so that many folks will find some way to latch on to it.

> solving problems is easy, it's understanding what the problem is that's hard.

I completely agree. These days, I work as a sysadmin/helpdesk monkey, and I am having this experience pretty much all the time - once I understand what is wrong, the solution becomes pretty obvious. Finding out what is wrong, though, can be really tricky. (More so on Windows - troubleshooting on Windows often enough ends in "Let's just reboot and hope it works next time")

> solving problems is easy, it's understanding what the problem is that's hard

Great way to lay it out. How many hours have I spent debugging just to come to the conclusion that the code does everything according to the requirements — it's the requirements which are buggy.

I agree with the basic and maybe its specially true for a project like linux kernel but there is another side to it too.

I usually refactor after understanding the code specially oddball sections which usually means it's handling some non trivial corner case. Now there has been a fair amount of cases where a rotten code has survived and caused other bits of rotten codes to be added because everyone keeps thinking it must have a purpose when it really doesn't. It is a hard problem but sometimes you have to take a bit of risk specially if the current code/interface keep decreasing the quality of all the new codes surrounding it.

And it's one of the reason when reviewing code I am extra hard on code that solves problem in a complicated way or do extra pointless work since those can cause these type of confusion in future.

I actually did a fair amount of this at work in the latest release. It was a combination of business rule change, data structure change and since it was the core security model we also did major interface change (the one linus is mentioning) so that the rest of the app/developer can work on a simpler/easier model. I spend more days discussing and planning the change then the actual coding for once and despite the few bugs at QA it had been a success. It had been one of the biggest change in my 10 years of work and one of the most stable. My takeaway from that is to iterate over the design a lot then iterate over the code a lot before really pushing it everywhere and probably have some break in between (if it's important enough) to have multiple go at it with fresh perspective.

This reminds of a piece of code I saw during my training, a web application written in Perl, by a Java guy, that I had to knead into shape.

When I was almost finished with it, the one ugly element that remained was a C-style for loop with a head that filled one and a half lines (about 150-160 characters) of seriously cryptic code, and its body was not much better.

I had been explicitly ignoring this loop while I was working on the application, because I had no clue what it did, and the app was working more or less they way it should.

But when I was finished slightly ahead of schedule, I could not help but use the free time I had left trying to figure out what the for-loop did. Otherwise, the code I had been massaging for a couple of months now was pretty pretty, but the prettier it had become, the more this ugly for-loop stuck out.

I started by adding a simple logging statement to its body that simply announced the fact that the loop was executing an iteration. Then I played around with the application for a while. Eventually, I took a look at the log file to see how often the loop had executed, and was rather baffled - the loop had executed a total of zero times.

I played around with the app some more, trying my worst to make that loop run at least once (which was, admittedly, hard, because I had no clue what it was for). Two hours later, I gave up and removed the loop.

I finished my training about eight months later, and at least during that time, I did not hear of it again. (I really would have liked to know where that loop came from, though.)

"I played around with the app some more, trying my worst to make that loop run at least once (which was, admittedly, hard, because I had no clue what it was for). Two hours later, I gave up and removed the loop."

That seems very risky, and I'd never have allowed that change to pass a code review. Just because you couldn't figure out how to make the loop execute doesn't mean that there aren't any paths through the code that would cause it to execute. The only safe way to remove it would be to prove that it can't ever execute -- e.g., the loop only executes if the variable foo is true (the condition is "foo && ..."), but foo is initialized to false and isn't modified anywhere else in the code.

>The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

Source: http://www.chesterton.org/taking-a-fence-down/

A good general guideline, but on occasion attempting to trigger the trap with a stick is a useful exercise. Just make sure you use version control ;)

In general true but sometimes it's almost impossible to prove that it is actually unwanted or plain wrong and you need to take some risk for the bigger benefit. It's not something to do lightly but it is actually needed sometimes. Our application has bits that hasn't been touched in years and no devel exists with experience in the said (problematic code) and if new development is needed and if that bit puts the new work at risk sometimes you have to make some judgement call and take the calculated risk.

First of all, I was a trainee. I do not know if that ever even entered production use. Secondly, the problem the web application was intended to solve was really trivial: Service managers used it to register customer machines that were intended to send email; they would enter the IP address of the server, the DNS domain of the sender and the account number of the customer to bill. The web application validated the data (fairly crudely - the spec I was given defined an account number as "consisting of decimal digits", and an email address as "containing an @-sign"), entered it into a database and sent an email to the firewall team so they would adjust their rule sets. Me and my supervisor looked at that loop intensely, and there was no explanation we could come up with why it would even be there in the first place.

(The whole thing was less than a thousand lines of not-very-dense Perl code, plus a few hundred lines of HTML templates. It's not like this was some highly complex piece of code.)

Reminds me of the CADT model

http://www.jwz.org/doc/cadt.html

Reply on news.ycombinator.com