So I just signed up for Showtime free trial on Roku - to watch the Joshua/Klitschko fight (awesome - i"m stoked for heavyweight boxing for the first time since the 80s). The whole app has like a 1-5 second delay when clicking something, before you see a response (but you do hear the roku sounds). I am 99% sure it's not network because all the other Roku apps are fine.

But apparently Showtime is ok with this level of delay, because Roku is way down the list of their platforms and w/e. What's the traditional engineering equivalent of that?

Scaling engineering teams, regardless of what kind of engineering, is extremely difficult. This is the primary accomplishment behind this - creating tools and processes that allow this many engineers to work together to create a single, extremely reliable product. Engineering at large is a social problem and one I don't think has ever been tackled at this scale outside of software engineering. Don't forget that the nature of software is that you have to keep things running and past decisions have consequences. Operating systems have to be backwards compatible and services cannot stopp running even while you're upgrading.

We're talking about a large nubmer of smaller projects that didn't really have to be coordinated and maybe some inventions that had a small number of people working on it. Most of the cost I imagine also has to do with material and manual labor, not engineering work. The resulting complexity of the system at large is also fairly low. Much of the planning behind is also not engineering but economic and political in nature I'm sure.

The measure here is not "impressiveness" but "complexity" - Einsten's special relativity is impressive but very simple.

This is the kind of complexity I'm talking about: https://cacm.acm.org/magazines/2016/...itory/fulltext

Again, the complexity involved here is fairly low - once the protocols are in place (designed by a very small number of people) - we're looking at a large number of smaller projects that didn't have to be coordinated and failures that could have easily been tolerated due to the design of the protocols.

I think you're really talking about something completely different - features add complexity even if they are not particularly valuable or impressive. Features require many more people to make decisions and have these decisions be coordinated in some way. And from a meta-engineering perspective, simply being able to add any value at this size without everything coming crashing down says a lot about the tools and processes that enable this coordination. My understanding is that other engineering professions are simply unable to design anything at all at this scale - they don't have the tools or processes to understand what's going on when projects reach this size. Let's not forget that the software industry provides other industries with the information management tools to understand what's going on with their own projects and these types of tools for software engineering are more advanced than what's available for other industries. On top of this, the top tech companies have internal tools for this because at that scale, commercially available tools don't even work.

This is why I find this talk of maturity preposterous coming from other fields. Managing processes is a fundamentally an information management problem that's best solved by software and it's completely absurd to believe that software companies, that literally provide all the other industries with the information management tools haven't already solved this for themselves.

I mean design of everyday products should be like a solved problem by now but we still have showers that have a 5 second delay for temperature control. I also bought this lamp from home depot not long ago where if you turn the rotating switch the wrong way enough times, the switch breaks completely. I'm not a particularly heavy person but last year, I've broken adjustable armrests on an office chair because they were adjusted all the way out and couldn't hold my weight when I lifted myself up on them. And somehow every single sippy cup we've ever bought for kids had major flaws - some combination of leaks, super-hard to clean, super-hard to put together, weird failure modes, etc. I'm sure if I think harder I'd be able to think of a lot more engineering failures.

https://en.wikipedia.org/wiki/Sturgeon%27s_law

Solid points. Counterpoint is to me those are the exceptions whereas horrible UI and software failures are the norm. Imagine a lamp where you have to google to figure out how to turn it on. That's like 75% of apps these days for me.

I wonder if for our grandkids "let me google that" will be like "let me get out the instruction manual" is for us.

Also it's like 2am - go to bed dude.

Interacting with candybar has reminded me of another thing. If ever, someone has the greatest idea ever - I could assemble an all time dream team.

Just saying if there's any connected people with great ideas reading this thread. Seriously holy **** we'd be good.

CSS - covered
JS - covered
React/Redux - covered
Testing - covered
Angular - covered
Node - covered
Java/Scala - covered
.net - covered (probably)
DBs - covered
DevOps - covered
Crypto - covered
Networking - covered
Web design - covered

And by "covered" I mean master-craftspeople that if you ever work with them once, you hold onto them for dear life.

Yes I'm a little buzzed atm.

Um... really? To me, this is like saying that because pre-Roman humans knew how to build bridges over water that new bridges spanning larger distances, accommodating more people, supporting modern vehicles isn't all that impressive.

The amount of raw human intellect and resources that have gone into scaling these products (particularly Google + Facebook) is astonishing. The research / products / tools that they've created/released in doing it, is also astonishing.

In terms of the 'engineering' debate, I've been hearing this ever since school where there was lots of debate about the differences between "Software Engineering" and "Computer Science". And lots of profs spent time trying to really reinforce that 'difference'. But in practice the whole thing has always struck me as a pointless debate (not that I don't participate in my share of pointless debates...) and aside from a few very specific cases almost entirely irrelevant.

Horrible UI is the norm in the real world too, we just don't pay attention as much.

A couple of examples:

* Pay attention to door handles in public buildings. A large number of them will be poorly designed from a UI perspective. When you see someone push a pull door (or vice versa) its a UI failure of an extremely basic feature.

* I've never lived in a house with more than 80% of the wired lights controlled from reasonable positions. I've lived in my current place for a few years now and I'm still hitting a blank wall regularly (instead of the wall with the actual light switch) in one particularly poorly designed room. (Note: This is because just like with Software implementation details often leak and influence design.)

* Have you ever thought about a car's basic UI? We have a design where once you start the car and put it in drive, the car moves by default. You have to actively keep the car from slowly rolling forward. That's kind of absurd (again, if you focus just on the UI and not the implementation details).

One big difference though is that in the real world our products/interactions are typically very trivial and single-purpose. We just train ourselves to use the UI presented and don't really think about how well it was actually designed. But even basic apps usually have more functionality than stand alone products/things. And when the stand alone products/things have extra complexity its usually just displayed through software anyway.

Edit: Just sat down to work and realized another one... office chairs. Put a random person in a brand new office chair with a few features like tilt / swivel lock / etc. and see how intuitive those designs are.

I think we can all agree that Industrial Engineering isn't real engineering.

I'm sorry I wasn't clear, but this is exactly what I was saying from the beginning.

I'm not arguing that software isn't hard near as much you are arguing that engineering is "easy." Building large buildings is complicated. Building large ships is complicated. Building large factories is or the Saturn V is complicated and engineering handled all of that before their were computers worth speaking of. If the only processes Software Engineering has in place to "truly" be engineering are too expensive to be used then that is a problem with the industry and not an excuse?

This still doesn't address that more than 50% of all software projects fail.

Software engineers are probably doing what they almost always do; working on the sexy stuff. No one wants to work on the tedious stuff and so we have bugs in 20 year old software still causing industry wide problems.

Software engineering is still pre-industrial, everything is considered a one off which hampers code re-use. How many bullet proof frameworks or libraries are there? How many new frameworks are released every year? Yes, the industry is still growing and advancing but that doesn't mean it is mature at all. DT is probably right, there is virtually no economic risk to companies that write bad software. There is virtually no economic risk to companies with bad security, credit card companies and banks hide the losses to prevent bad publicity. Maybe open source can change this but how many times have you wasted an afternoon trying to use an open source project only to find it hasn't implemented the feature you needed or implemented it in such a way you can't use it?

When was the last time someone died from a bad power socket or standard electrical connection on a device?

Again, I'm not saying software developers aren't doing great things, I'm saying they actual practice of developing software has a long way to go before it is as mature as Engineering. Part of the problem is that no one wants it to be that mature because then it will be boring with lots of documentation, and no one wants to write documentation.

Welcome to the Internet!

+100 to this.

fwiw, i'm constantly noticing these details in the real world and i consider what i'm not doing not as applying UI analysis to the real world, but as a single endeavor that happens often to have two names. the line between the two is wholly artificial, unless you take an arbitrary delimiter like "UI applies only to screens." once you start seeing through this lense, examples jump out at you everywhere.

similarly, writing clean code is just producing good UI for other developers (or yourself). and writing clear prose is good UI for ordinary readers. the specific sub-specialties have their own quirks and expert skill sets, but the overarching similarities are more striking and interesting imo.

I took a UI course in university with an amazing prof. It was one of those courses that could have been horrible, but he was absolutely brilliant and fascinating. Ever since that course I've been way more away of the 'interfaces' we use all the time.

Edit: We also covered a lot of human learning in that class. So an example was how he had a confusing light switch situation in his house and he internalized it as "this set-up is backwards". But he talked about how he'd go through phases where that would work, but then he'd go through phases where he'd get use to it, so then "this set-up is backwards" meant he'd do the wrong thing. I'm probably butchering that story, but it was great.

Lol, this reminds me of how at work here we have a bathroom with 3 sinks. 1 sink has 1 knob that turns in the opposite direction, so now I'm ruined for all the sinks in that bathroom. I look like such an idiot when I'm spinning all the knobs back and forth trying to turn the water off lol.

two general principles this is an example of that arise in programming all the time.

"special cases are a disaster" (rethink your solution so the special case is subsumed in a general principle. eg, modular arithmetic instead of checking if a value is larger than X. 0, negative numbers, and imaginary numbers are all examples of this in mathematics)

"consistency of interface" (so i only have to learn one thing, instead of many)

We have a light in our house that is controlled by 3 switches. 2 of them are a classic XOR arrangement. If the light is off and you flip either one, it'll turn on and vice versa. The 3rd is in series with these 2 as an AND switch. This is SUPER frustrating because if you "turn off" the lights with the switch the other 2 switches don't do anything and you have to remember to cross the room to the 3rd switch and turn it on. It's in a switch panel with 3 other switches. I marked it with a piece of tape and I BEG my wife to not use it, because if I leave our bedroom in the middle of the night and that switch is off I have to cross the house to turn on the lights outside the bedroom.

we have a similar situation, which must be common, created by a light-switch controlled fan. The fan obviously has pull-chains as well, so it's often a two or three step process to get the light or fan on, depending on the order in which you make your attempts. A nice example of the inherent evil of mutable state.

The water faucet example made me immediately think of switches I've encountered similar to Rusty.

Somehow people who design switches seem to collectively decided minimum viability is all that's necessary.

A project I worked on at my old company with a partner company paid off, the head technology guy on that project put in a good word for me and got me a senior analyst gig with the partner. No more looking for support roles starting with a 20% salary cut! Yata!

Contrats kerowo. Is this an engineering role? :troll_face:

Actually I forgot to mention - these lights are on a fan also, with a remote control. If you turn them off with the remote you can't change that with any of the switches. And if you can't find the remote, well, **** you.

Has anyone here used RAML? I'm having a really hard time getting a question googled.

I have written a RAML doc for our API. I use it, among other things, to generate docs for our API. Great!

But, I want to share the RAML document directly with other people who might be interested in it. It is, after all, a form of *machine readable* documentation. How the heck do I do this? I can't find anything about it, or whether it's something anyone even does.

Our raml setup is split between a dozen or so files, it'll probably balloon to more like 50 or 60 when I'm done, because it includes JSON schema and examples for every endpoint. RAML lets you embed these schema in docs by file name.

I mean, I made an endpoint where you can get any of the raml files but I haven't caught wind of really even any tooling that is intended to consume such endpoints, so I have no idea if I did it right at all.

OK I found an app that reads raml specs from a url, and it seems to handle mine fine, so I guess I did ok.

Do you mean share internally or externally? Internally, our product manager just kept them in a git repo. Externally, I think they get fed into documentation systems for documenting APIs. When looking into documenting our API that's what I found, no straight RAML viewers or anything.

Both, but the "internal" sharing should be considered external. If I tell people "you can find the raml docs in this directory in this git repo" they'll essentially never look there, probably, and it's kind of much to ask someone to check out our repo just to get a couple of docs.

I basically just made an endpoint like /raml/ and if you go to, say, /raml/external_api.raml then it'll get the root doc. The root doc refers to subdocs, like "users/users.raml" so if you go to /raml/users/users.raml then it'll get that. It's basically just mirroring the directory structure via a URI.

There's a thing called "API Notebooks" that are a little bit like Jupityr notebooks (however the hell you spell that) that can take one of these URIs and read the whole structure and interpret it.

We use the raml file to make HTML docs, sure, but those are for people to read. By providing access to the raw raml, people can make just-in-time automated SDKs and stuff like that. Or they can pre-verify their inputs before sending them to us. Or they can use the examples and schemas to make mocks and use them in their testing, etc.