←back to thread

917 points cryptophreak | 9 comments | | HN request time: 0.001s | source | bottom
Show context
squeedles ◴[] No.45761639[source]
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

replies(22): >>45761688 #>>45761787 #>>45761946 #>>45762556 #>>45763000 #>>45763132 #>>45763419 #>>45763515 #>>45764215 #>>45765589 #>>45766183 #>>45766281 #>>45768514 #>>45769691 #>>45771196 #>>45771307 #>>45771846 #>>45772026 #>>45773411 #>>45773951 #>>45776266 #>>45779651 #
DrewADesign ◴[] No.45761787[source]
Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With interface design, everybody knows what a button does and what a text field is for, and developers know more than most about the tools used to create interfaces, so the language seems simple. The problems you need to solve with that language are complex and while failure is obvious, success is much more nebulous and user-specific. So much of what good interfaces convey to users is implied rather than expressed, and that’s a tricky task.
replies(8): >>45761895 #>>45762139 #>>45764045 #>>45764889 #>>45766812 #>>45767103 #>>45767301 #>>45774902 #
makeitdouble ◴[] No.45767103[source]
> creating good interfaces (for people that aren’t developers.)

This is the part where people get excited about AI. I personally think they're dead wrong on the process, but strongly empathize with that end goal.

Giving people the power to make the interfaces they need is the most enduring solution to this issue. We had attempts like HyperCard or Delphi, or Access forms. We still get Excel forms, Google forms etc.

Having tools to incrementaly try stuff without having to ask the IT department is IMHO the best way forward, and we could look at those as prototypes for more robust applications to create from there.

Now, if we could find a way to aggregate these ad hoc apps in an OSS way...

replies(2): >>45767704 #>>45769563 #
marcus_holmes ◴[] No.45767704[source]
I have nightmare stories to tell of Access Forms from my time dealing with them in the 90's.

The usual situation is that the business department hires someone with a modicum of talent or interest in tech, who then uses Access to build an application that automates or helps with some aspect of the department's work. They then leave (in a couple of cases these people were just interns) and the IT department is then called in to fix everything when it inevitably goes wrong. We're faced with a bunch of beginner spaghetti code [0], utterly terrible schema, no documentation, no spec, no structure, and tasked with fixing it urgently. This monster is now business-critical because in the three months it's been running the rest of the department has forgotten how to do the process the old way, and that process is time-critical.

Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that. We have to fix what we can and get it working immediately. And, of course, these fixes cause havoc with the project planning of all our other projects because they're unpredictable, urgent, and high priority. This delays all the other projects and helps to give IT a reputation as taking too long and not delivering on our promised schedules.

So yeah, what appears to be the best solution from a non-IT perspective is a long, long way from the best solution from an IT perspective.

[0] and other messes; in one case the code refused to work unless a field in the application had the author's name in it, for no other reason than vanity, and they'd obfuscated the code that checked for that. Took me a couple of hours to work out wtf they'd done and pull it all out.

replies(6): >>45768297 #>>45768433 #>>45768445 #>>45769911 #>>45770836 #>>45771293 #
1. GTP ◴[] No.45769911{4}[source]
> Spinning up a proper project to replace this application isn't feasible in the short term, because there are processes around creating software in the organisation, for very good reasons learned painfully from old mistakes, and there just isn't time to go through that.

I assume those processes weren't applied when deciding to use this application, why? Was there a loophole because it was done by an intern?

replies(2): >>45770544 #>>45770589 #
2. rob74 ◴[] No.45770544[source]
Well, if someone (especially an intern) who is not in the IT department decides to write an application, it's pretty obvious that they are not familiar with (and therefore won't follow) the processes of the IT department. That's the problem with these more "democratic" development environments: if something is beginner-friendly, beginners will use it...
replies(2): >>45770652 #>>45772620 #
3. dspillett ◴[] No.45770589[source]
Simple things, or even complex prototypes, get created in office apps because the office apps are their, have the flexibility, and you don't need to get IT to install something new (or allow you to), or convince finance to let you pay for something new, or convince compliance/security/other than the something new is safe anyway, etc. Also in a larger company, once the discussion of developing or buying something comes up lots of other potential stakeholders might raise their heads above the parapet and want to get involved (“Could our dept use this too?”, “We would need it to do Y as well as X…”, “That sounds useful, but it should be us doing it instead”, etc.), and suddenly the quick PoC that has been barely started has become a series of interminable meetings.

The loophole is that if you have Office or similar you have a variety of development environment, IT/compliance/finance aren't caring what files you produce with the applications you have, and no one else is paying attention initially either, but would have a say (and a procedure for you to follow) if you wanted to bring in or create a new application. The usual process is bypassed.

This is more commonly associated with Excel, but it applies to Access too (less so than it used to, but there are still plenty people out there who rely on it daily).

Once the demo/prototype/PoC is there it is a lot easier to “fix up” that than spin up a project in anything else, or get something else in that is already available, for the same reasons as why it was done in Excel/Access in the first place plus the added momentum: the job is already at least part way done, using something else would be a more complete restart so you need to justify that time as well as any other costs and risks.

[Note: other office suites exist and have spreadsheets & simple DBs with similar capabilities, or at least a useful subset of them, of course, but MS Office's Excel & Access are, for better or worse, fairly ubiquitous]

4. GTP ◴[] No.45770652[source]
Yes, the intern will not follow the procedure, and likely isn't even technically required to do so. But, before the application becomes a tool actually used inside the company, there should be some quality control done.
replies(1): >>45771368 #
5. listenallyall ◴[] No.45771368{3}[source]
Think of the management structure which arranges, and is satisfied with, tedious, repetitive, manual paper-pushing processes - such that an INTERN can immediately see the efficiency benefits that would come with automation, and doesn't just suggest doing so, but actually builds a program (in limited intern timeframe), that is so helpful it's quickly picked up by multiple employees.

Then think again of those managers getting paid manager salaries who couldn't figure this out themselves - or worse, the ones who want to shut it all down because he didn't "follow the procedure" (the procedure of not doing anything useful???)

replies(1): >>45774016 #
6. jyounker ◴[] No.45772620[source]
Another point of view is that the IT department isn't meeting the users' needs, and that they're bypassing IT because they just want to get their work done.
7. GTP ◴[] No.45774016{4}[source]
Shutting it down due to a technicality about not following a procedure != shutting it down because it is an unmaintainable mess, while also tasking IT with implementing the same core idea, but in a proper way.
replies(1): >>45775031 #
8. listenallyall ◴[] No.45775031{5}[source]
Lol, define "proper". If they were so knowledgeable, why hadn't they implemented something before the intern arrived?
replies(1): >>45777521 #
9. GTP ◴[] No.45777521{6}[source]
There can be many reasons, e.g. management giving them other tasks.