Comment by nkurz | Hacker News Reader

Comment by nkurz | Hacker News Reader

A couple of comments here mention how great steam heat feels, apart how noisy it is. This is ironic, as one of Holohan's main points is that when operating properly, steam heat is silent. The problem is that most people have never experienced a properly operating steam heat system. Here's some quotes from the intro to his Greening Steam (which is a great book, which you should definitely read if you have a steam heat system):

Steam Heat Should Be Silent

Water hammer, that banging and knocking that is so prevalent in steam heating, is not normal. Don't let anyone tell you that it is.

Water hammer is also destructive. It can break pipes from fittings and cause injury. It's not normal. It has definite causes, and you can make it go away.

Hissing air vents aren't normal. In a well-balanced steam system, you should never hear air venting. When a vent makes noise, it's trying to tell you that it's handling too much air.

Holohan's main conceit is that there are very few plumbers who understand steam heat, and as a result, there are very few systems that work as designed by the "Dead Men". The idea that steam heat is inherently noisy is one of the main myths that he wants to dispel.

Tying this back to HN, there's probably some useful parallel here to systems architecture and maintenance programming. How many systems will keep working as well as they were designed after several generations of "repairs" have been performed on them? How can one design systems to make it more likely that they will continue to work as designed?

The problem as usual is with the users not the system. If anyone in your building turns the valve on their radiator off (because their space is overheated) then the water will condense and when they open it again the entire system will hammer, forever, until the building engineer drains it. As for the air vents it seems that building supervisors just can’t resist painting them, which renders them inoperable. They should know better.

So in summary steam is wonderful as long as humans don’t get involved.

If anyone in your building turns the valve on their radiator off (because their space is overheated) then the water will condense and when they open it again the entire system will hammer, forever, until the building engineer drains it.

Theoretically, I don't think this is correct. And in practice, I'm sure it's not always true. That is, I've tuned up a steam system using Holoway's advice, and there was no problem with turning individual radiators on or off.

In normal operation, the steam is condensing in the radiator, and then draining back to the boiler by gravity. Opening the valve after a period of nonoperation is not significantly different than the rush of condensation one gets at system start up when the radiator is cold. If the pipes are layed out correctly, when the valve is opened the water will drain back to the boiler with no outside action required.

What is true is that the standard "one pipe" steam radiators work poorly when the user decides they want half the heat, and turns the steam valve halfway. In this case, the higher speed of the incoming steam through the smaller opening prevents the water from flowing out, and the radiator works poorly. The correct approach to variable heat on one-pipe steam systems is an adjustable exit air valve. Still, this should also "fix itself" quickly as soon as the shut-off valve is fully opened.

> The correct approach to variable heat is an adjustable exit air valve.

I always wondered why the radiators in some buildings had two apparent temperature controls, one at the bottom of one side (generally a big gate valve) and another at the top of the other side (which I presume is the "exit air valve").

As a student, nobody ever told us how to actually regulate the heat, so there was a lot of randomly opening and closing valves until the thing either got hot or cooled down as needed. Or, more commonly, you just ran the thing full blast all the time and opened a window when it got too hot, titrating the cold air from outside against the overwhelming heat from the radiator.

A couple of laminated instructions stapled to the wall near each radiator probably would have made the system perform much better.

> then the water will condense and when they open it again the entire system will hammer, forever, until the building engineer drains it

That's not true. I've had issues with my house steam system in the past where I added too much water to the furnace and draining the furnace did the trick. Any excess water will simply turn to steam and cycle itself out of the system.

When the user doesn't understand the system, than it is the systems fault.

I can't believe you are being downvoted for this. It's absolutely correct and consistent with my point: a system that's abstractly superior but which cannot survive contact with humans is not a good one.

>The problem as usual is with the users not the system.

Never the right attitude. If users have constant issues with a system, its a system flaw. You can't upgrade the users.

> You can't upgrade the users.

You absolutely can. You just have to state and keep stating that the system is for adults who can be bothered to read half a page of instructions once in their life, instead of fostering a culture of ignorance.

We have a similar problem with software UX, too.

People are not going to read and remember detailed instructions for every one of the hundreds of devices in their daily lives. If that means they're stupid, then you have to design for stupids. It sucks, but that's how it goes.

You're quite right that this is an ongoing problem in software UX. The problem is devs who insist that the user should accommodate the software rather than the other way around.

It's pretty frigging amazing though with software that people will absolutely not spend a half hour reading documentation before they just start trying to poke and prod at things. In other industries, you have to go through mandatory trainings on a regular basis on your equipment.

> People are not going to read and remember detailed instructions for every one of the hundreds of devices in their daily lives.

I'm not saying hundreds. I'm saying couple dozen. Anything you interact with more often than twice in a lifetime. Nobody complains that they have to learn how to use a pen. Or a bike. Or a car. Or a gas stove. Or a microwave oven. People just suck it up, spend the necessary effort, and enjoy significantly improved capabilities. If you use something daily, you owe it to yourself to learn how to operate it.

What we have with modern UX trends is a culture that despises learning. It's a marketing artifact - a software sells by first impression, not by value delivered, so the less learning user needs to get first results, the easier it is to sell a product or service.

> You're quite right that this is an ongoing problem in software UX. The problem is devs who insist that the user should accommodate the software rather than the other way around.

I meant precisely the opposite and you know it :). The rationale is this: the only way to have software that can be used by a newcomer to its full potential within first 5 seconds of exposure is to dumb the software down to near-uselessness. Which is the dominating trend nowadays. Lowering the beginning of the learning curve by flattening the entire curve creates a hard ceiling on utility of a piece of software (or hardware). If there's nothing to learn, the user is forever stuck at beginner productivity levels. Which means the software isn't really providing much value (it probably provides negative value if the user was forced to upgrade from older software which allowed for mastery).

> If that means they're stupid, then you have to design for stupids.

No, because it means they're being stupid, not that they are "stupids", like it's a zodiac sign. So they should stop being stupid.

> The problem is devs who insist that the user should accommodate the software rather than the other way around.

Writing good documentation is accomodating users, and there is a lot of stuff that is very simple but still can't keep to a common way of how things work (because it's all mostly fluff functionally anyway, and needs to "differentiate itself" in some gimmicky way), and none of it has decent documentation -- so people are left to ask each other in random forums or elsewhere how anything works. IMO that's being lazy, and not paying users for work the developers should have done.

If it was designed "for stupids", it would have very clear instructions in big letters which still would hold true after 20 years, because "stupids" don't always have the latest thing.

https://www.gpsoft.com.au/help/opus12/index.html

Nobody remembers that, or reads all of it just for fun. But it's all there if you need, thorough and up-to-date. Old Opera was also like that, and none of my non-techie friends or relatives ever had problems with it. I'm sure many other programs still are, as in they do follow allll the best practices an application "designed for dummies" would, but then they also have a good documentation, and maybe a CLI interface and other things a programmer might want so called power-users (as opposed to powerless consumers?) to have. Current users are getting ripped off by being trained and conditioned by marketing departments, not peers and teachers with good intent.

> power-users (as opposed to powerless consumers?)

I like to think of it in terms of frequency/duration of use. There may not be many (relatively) "power users", but there are a lot of 9-5 users. People who have to work with a piece software 8+ hours a day at work, day in, day out. If a piece of software has near-flat learning curve, it's contributing a lot to the misery of those people. Like, 6 hours straight of clicking through a slow web UI kind of misery, where unbloating the UI would cut that literally in half, adding keyboard shortcuts would cut that in half again, and a semi-decent batch mode would let them be done in 15 minutes, go get coffee, and start working on something else.

Where's the "value" such "user-friendly" software provides the users again?

And here also lies the answer to the age-old question - why people use Microsoft Excel for everything? Because it's a tool for "power users", with no ceiling in sight. It's flexible where most dedicated software is stiff, which gives people a way to optimize their work.

I also think saying "we don't bother with documentation or configuration because nobody reads or uses that" is kind of a self-fulfilling prophecy.

> Treat people as if they were what they ought to be and you help them to become what they are capable of being.

-- Johann Wolfgang von Goethe

That always risks being patronizing, but at least we should allow users options and deeper documentation, for those who want to use them -- they shouldn't get punished by being restricted to the lowest common denominator. That doesn't mean there can't be friendly defaults, "wizards", and whatnot.

> I also think saying "we don't bother with documentation or configuration because nobody reads or uses that" is kind of a self-fulfilling prophecy.

Oh yes, and it's so deeply ingrained in the culture.

At my previous job, our customer made us use a pretty crappy, proprietary integrated system for task management, bug tracking and version control. Everyone hated it with passion. It took me over a year to finally stop and think for a moment - that maybe it has some more efficient modes of working, and maybe there is some logic to its organization? I clicked Help -> Manual and, lo and behold, I was looking at a large compiled help file describing everything. Every functionality, the fundamental concepts behind the software's UI and data representation. Hell, it even mentioned the API. 30 minutes later, I still didn't like the software, but I was finally somewhat comfortable with it.

I was probably the first person to do that in that company. A lesson here is that unfortunately, the instinct to bitch about software instead of trying to find a manual is strong even in power users. I took that lesson to heart, and these days I'm e.g. very friendly with Info pages in my OS. Turns out if software you regularly use has a decent manual, reading it (or at least skimming, and I mean cover to cover) has absurdly high payoff.

> they shouldn't get punished by being restricted to the lowest common denominator. That doesn't mean there can't be friendly defaults, "wizards", and whatnot.

Exactly. Lower the start of the learning curve, but don't flatten it entirely, don't dumb down your application for the sake of "easy to use". Power always comes with some amount of complexity and learning.

>You can't upgrade the users.

Yes you can. It's called education. People are generally not idiots. Make it easy for them to learn how to do something right and the overwhelming majority will do that thing right. It's when you leave them to figure out something they have no domain knowledge in on their own that causes problems.

Operating a radiator should not require education or domain knowledge. Its only affordances are "turn up" and "turn down," and neither of those should lead to a failure mode other than touching hot metal and singing yourself.

> The problem as usual is with the users not the system. If anyone in your building turns the valve on their radiator off (because their space is overheated) then the water will condense and when they open it again the entire system will hammer, forever, until the building engineer drains it.

If that's true, it would definitely be a problem with the system, not the user. A heating system that malfunctions semi-permanently if you turn off one radiator is not a good heating system, and it's not reasonable to demand that residents swelter in their rooms to accommodate the system's failings.

> How can one design systems to make it more likely that they will continue to work as designed?

Perhaps it would need to be antifragile in some way, and have direct immediate feedback on "bad repair" vs "good repair".

Reply on news.ycombinator.com