Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I could do that in a weekend (2016)

danluu.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: I could do that in a weekend (2016)

#31

Post by criddell »

pgm8705 wrote: post #5

Similar thing with comments whenever a Slack related article ends up on HN. "I don't understand how a shitty IRC clone is worth billions of dollars!" or "Why would anyone use Slack when Matrix is free!" I often wonder if these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth and/or how much detail and thought goes into making it usable f…

> these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth

Are you saying that sending messages back and forth involves a lot more complexity that you don't see or that Slack does a lot more than just messages?

Re: I could do that in a weekend (2016)

#32

Post by adt2bt »

jeffreyrogers wrote: post #8

One other thing he touched on in passing: people are assuming they'd know what to build from the start. Even in relatively trivial applications a lot of work goes into finding the right way to express what you're trying to build. I recently worked on a small app and spent 40 hours trying out different approaches to the user interface. The solution I went with could be coded up in about 2 hours, but I had to do 38 hou…

I had a similar realization with food recently, bear with me.

You ever hear how in certain cultures, Mom's food is the best? Now, of course there's nostalgia involved. A hint of home can make your taste buds sing just a bit louder. But also, even for a 'simple' meal, there are so many options a chef can make that subtly change the meal.

For example, looking only at one ingredient, you can end up with a dizzying amount of options. For example, do you use chicken thighs or white meat, sear it first or let it braise, brine it or salt it right before going on, use a jar of pre-ground spices or add your own concoction of 5 spices? Each of those is a choice, and only one set of choices ends up with Mom's chicken cacciatore.

In software, any good UX is usually the result of thousands of intentional choices. It takes trial and error and research and actually time spent using the damn thing to figure out the tradeoffs involved in many of those choices. Just like it usually takes new chefs dozens of crappy, burnt, lifeless meals before developing the taste required to make those tradeoffs effectively.

Re: I could do that in a weekend (2016)

#33

Post by tshaddox »

moksly wrote: post #4

I think this article raises a lot of good points about the weekend prototype, but I also think there is some merit in the question of “what do all those people do?”. I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen whic…

> I also think there is some merit in the question of “what do all those people do?”

There is merit in the question, but I think the answer is less "the core product is a lot more complicated than it seems" and more "a big software company with lots of eyes on it can make even more money by hiring more people to create more products that are ancillary to the core product."

Re: I could do that in a weekend (2016)

#34

Post by tshaddox »

criddell wrote: post #31
pgm8705 wrote: post #5

Similar thing with comments whenever a Slack related article ends up on HN. "I don't understand how a shitty IRC clone is worth billions of dollars!" or "Why would anyone use Slack when Matrix is free!" I often wonder if these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth and/or how much detail and thought goes into making it usable f…

> these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth Are you saying that sending messages back and forth involves a lot more complexity that you don't see or that Slack does a lot more than just messages?

That's kinda a "gotcha" question, because it's not clear what your definitions are. For example, is authentication (single sign-on, etc.) part of what you describe as "sending messages back and forth"? Are files, screen sharing, video calls, etc. still "just messages"?

Re: I could do that in a weekend (2016)

#35

Post by Jtsummers »

NortySpock wrote: post #27
moksly wrote: post #4

I think this article raises a lot of good points about the weekend prototype, but I also think there is some merit in the question of “what do all those people do?”. I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen whic…

Thinking back on the overall strategy, would it have been better to "just" digitize, OCR and timestamp the coordinating documents for logging and audit purposes? A "document management system" rather than "an eldercare management system"? That way it's "just" "Pull up the most recent documents relating to or updated for patient Doe, Jane" or "What has changed in the medications prescribed in this district?" The Docum…

Right. When I've seen these kinds of efforts they seem to take one of two paths:

1. Specialized, monolithic systems. These try to do everything for everyone and usually end up devolving into the 12-month (or longer) release cycles. "Monolith" doesn't mean monolith vs microservice in this context. Just that the system is trying to be all encompassing. This is the norm. It rarely works well because it massively increases the cost for change (money, personnel, and time) even for what should be minor things (Oh, you need a custom report? We'll get it to you next year.).

2. Generalized, flexible systems. A document management system like you discuss would be one potential solution. These tend to be more data-oriented (sharing a common database or a common set of databases) with potentially custom front ends. The front ends tend to permit flexibility for the user, including generating their own queries and workflows. These usually work out better, but are not that common among mega corporation or government digitization efforts.

The former is easier to "sell". You get to manage a massive contract, it looks more productive than it is. The latter tends to be more grassroots, an internal effort. The former is highly visible, the latter is nearly invisible.

Related, people tend to overvalue work that appears difficult and undervalue work that appears easy. The second approach tends to make modifications "trivial", so the managers ask, "What are we paying you for?"

Re: I could do that in a weekend (2016)

#36

Post by elcritch »

abnry wrote: post #11

Sounds like the Pareto Principle at play: 80% of the product is created with 20% of the effort. It is getting the next 19%, then 0.9%, then 0.09%, and so on, that is the challenge.

That 0.9% then 0.09% are also where the real success comes from in many fields.

Re: I could do that in a weekend (2016)

#38

Post by criddell »

tshaddox wrote: post #34
criddell wrote: post #31

Earlier quoted context omitted.

> these folks haven't even bothered to actually use the software and realize how much more it does beyond sending messages back and forth Are you saying that sending messages back and forth involves a lot more complexity that you don't see or that Slack does a lot more than just messages?

That's kinda a "gotcha" question, because it's not clear what your definitions are. For example, is authentication (single sign-on, etc.) part of what you describe as "sending messages back and forth"? Are files, screen sharing, video calls, etc. still "just messages"?

I didn't intend it to be a gotcha question.

> Are files, screen sharing, video calls, etc. still "just messages"?

I wouldn't think any of those as messages that a basic message-only client would have.

I guess that's the distinction I was after - was the person I replied to talking about all the complexity of a basic message-only client, or were they talking about the complexity of all the stuff beyond that.

Re: I could do that in a weekend (2016)

#39

Post by WesolyKubeczek »

Sometimes, though, you do need to scale back to a weekend prototype. Understanding what it takes to scale the system is good, but the analysis paralysis from imagining that every problem must have a Facebook-scale solution is silly too.

I mean, those Volvo XC90s are damn slick, but somehow my local pizza place delivers hot tasty stuff on time in an old Fiat Seicento. I think the pizza quality would suffer if the owner invested in a more reliable and better car.

Re: I could do that in a weekend (2016)

#40

Post by WesolyKubeczek »

shuckles wrote: post #26
moksly wrote: post #4

I think this article raises a lot of good points about the weekend prototype, but I also think there is some merit in the question of “what do all those people do?”. I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen whic…

In cases like this, it’s always useful to have an expansive definition of “user”. For example, day to day experiences for caretakers might have degraded under the new patient information system, but maybe it’s now easier to produce charts which bosses want. For better or worse, they are users of the system as well. To whom a change is worthwhile often leads to unexpected beneficiaries with unexpected motivations.

So maybe let the caretakers work in peace and have one additional person draw pretty charts out of thin air which would be just as good?

I've been working on a product which everybody was convinced had Gantt chart functionality. Said functionality was using the venerable Math.random() top to bottom, with nobody being the wiser.

Post reply on HN