disordinary

We lived it in the early 2000s until Firefox broke the monopoly and it was a dark time to work in web.

Or, is the market share including mobile where Chrome and Safari are king. If we just look at desktop market share is Firefox higher?

Development.

When you're developing in a container you can guaranty that the environment is the same on your PC or in the cloud.

Also, the same argument you had for shared resources in Linux, when you're running Linux on a VM locally on your desktop because you want linux tools or applications, then you want as much memory management as possible.

But, because healthcare is public in NZ you wouldn't bother with the brand names as you'll have to pay for them (generics are funded by the taxpayer through Pharmac, which is the crown entity that is responsible for buying all publicly funded medication for NZ).

It's like Private hospitals, we have them, but very few people use them as the public system is better equipped and paid for by the tax payer.

Nope, and they're annoying because I accidentally click them and random stuff happens because I have no idea what they're mapped to.

The first album is dark enough to appeal you'd think.

You can do it both in Terraform and also at the resource level in Azure itself.

He should have specified that, because we're talking global here.

A 24% spike in the US is absolutely insane.

Most of those diseases have a long tail so we won't see the death rate from them for 2020 probably. They'll increase the death rate in a year or two unfortunately.

There was a global 24% spike in roadway deaths? I find that hard to believe. Please provide evidence. In my country we saw a 10% reduction in road deaths through 2020.

Not only that, but the covid restrictions have meant that the normal death rate is lower. Because people aren't traveling and commuting the road toll is down, because people are at home and social distancing workplace deaths are down. So excess mortality is up and the base deathrate is down meaning excess mortality is actually higher than shown.

I'd imagine the HN crowd cares less than executives at large organisations and government departments. There's a requirements for industries and businesses to either own their own data or keep that data onshored in their jurisdictions.

When it first launched we talked to the guy who made it (pretty sure it started as a side project) and IIRC it was backed by a relational database with every block being a row and a lot of joins that make up a page. Hopefully they've optimised it since then, but if that's still the architecture it's going to be hard to get performant.

Just a wiki really which is made up of smart blocks. I've used it a couple of times professionally but the companies have usually moved on to something simpler after struggling to get buy in across the team. It can be daunting when you first use it, although very powerful.

AOL was a big brand name as a dial up provider right? Why didn't they just move into dsl, cable, fibre, mobile broadband, etc? It seems like they abandoned that business completely and moved into media.

There's a risk vs productivity balance. Most people develop for systems which are connected to the internet and can be updated on demand, in that case it makes sense to "shit out javascript" because we can go back and optimise and fix things later. That doesn't mean you can't use proper design patterns, but you shouldn't front-load work for something which is most likely going to be wrong for the customer when they see it regardless.

The fact that we can iterate on something once it's released means that engineering in a software sense is different from any other discipline which we call engineering.

I hope Dan doesn't get much hassle or negative feedback from this. As a free service it's always going to be all care and no responsibility and as someone from outside of a major timezone, I find it very useful.

Yes, but at a higher level and less formally than UML.

A sequence diagram doesn't need to be ordered in a time sequence like UML, it can be good enough to just articulate and number the flow of information on a normal solution diagram.

A class diagram assumes we're using an OO language - we need to define schemas for data, but not classes. The engineering team knows how to structure their code, as an architect all we need to worry about are the boundaries.

Yep, also we're leveraging components that other organisations build more. For instance, we used to build our own messaging systems, now we use open source projects like Kafka. We used to write our own wire protocols, now we use HTTP endpoints with JSON payloads. We used to write our own authentication systems, now we use authentication libraries. Our patterns have standardised to the point that we don't need to design and document nearly as much as we used to.

Sure, but the higher level you go the less detail you need. UML gets right down into the weeds, this is where design as code and documentation as code comes into play.

Plan at a higher level, execute at a lower.

Yep, they taught us RR in uni in the early 2000s as well, this was in New Zealand.

Sure, but you don't have to go as heavy handed as UML. You have to wonder if a visual diagram is the best way to go into detail or should we use other ways of delivering that information?

I'd say this is suitable to give to an engineering team, along side a table with some endpoint detail, or even just the swagger. https://v2.developer.constantcontact.com/dotAsset/991381b5-0...

Whereas this is too much information and too hard to decipher at a glance: https://docs.microsoft.com/en-us/azure/active-directory/deve...

Diagram the higher level, leave the detail to other mechanisms.

Sure, but agile is about breaking up work into small chunks and showcasing value in those small chunks. If you're doing it properly you'll be able to look at your velocity and know that you're falling behind schedule. Or, your customers will be able to see early that the thing your building doesn't suit their needs.

It means you can plan for and adjust early, rather than the week before a deadline.

Basically, we can't plan and estimate very well in tech, but it's easier to be accurate in our plans and estimates in smaller chunks than in larger.

Saying that, agile is about delivery rather than project management, and there always needs to be a larger roadmap to track features against - which is how we know if we're going to be late or not.

The reason we stopped with UML and other front heavy planning methodologies is that what we planned was always wrong.

Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway.

It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts.

By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs.

Also, it turns out that engineering teams know better how to develop a piece of software than architects.

We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have.

All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.

You said you solved the problem for yourself, which of those three was the original problem you were solving?

I haven't downloaded the demo, but Splink, ELK, SumoLogic, whatever, and even visualisation tools like PowerBI, Tableau, Grafana, etc. are all complicated and need a lot of effort to setup and learn. A lot of businesses rely on excel for their data, just like they rely on outlook for a CRM. There is probably a market for a solution which runs on your desktop without too much fuss, and sits somewhere between excel and big data.

Fair point, I think it depends how you frame it - and it is a fine line between being earnest and sleazy. As a founder you've gotta get comfortable walking it.

Here's some feedback after I unearthed your homepage:

You say users of the tool aren't on HN (which is a technology audience), yet your landing page is talking about technology and not the problem your solving. My guess is the audience for EXCEL are Business Analysts, admin staff, accountants, executives, etc. And not people in technical roles who'll get excited by the technology.

-------

You start off with some questions, but only one of them means anything to me:

"HAS YOUR BUSINESS AN EXCEL PROBLEM?" What is an excel problem? (Also, "DOES YOUR BUSINESS HAVE AN EXCEL PROBLEM?" reads better to me)

"DO YOU HAVE HUNDREDS OF UNMANAGED SHEETS RUNNING REPORTS?" This is the only question I can really answer.

"DO THEY TELL YOU IT WOULD TAKE TOO MUCH TIME TO REPLACE WITH PROPER APPS?" Who are "they"?

then you have:

"LIKE EXCEL, JIG IS A LIGHTWEIGHT SOLUTION TO CREATE DYNAMIC BUSINESS REPORTS AND APPS IN MINUTES. " This is fine

"UNLIKE EXCEL, JIG FILES ARE AUDITABLE, MAKING JIG APPS INHERENTLY SAFE. " What does safe and auditable in this context mean? What benefit does that give me? Surely the main benefit is the ergonomics and speed of accessing my data and safety and auditability are just side effects?

So, as someone who doesn't use Excel a whole lot, but I've seen businesses which run on very complicated excel spreadsheets without too much hassle, I'm struggling to see the problem.

As above, you talk about electron, and JavaScript, and auditability - which is fine for a technical audience, but if I'm a spreadsheet user I couldn't care less if it's built on Electron, or Flutter, or Qt, I just want to know how it helps me.

Would an excel user really care about a REPL (or even know what it is?) Or Version control, or the fact that something is or isn't on the cloud?

Surely the people who care about developer tooling would just be doing the visualisation in R or Python?

-------

I'm not saying there isn't a problem here, but perhaps you're not framing it the right way for the right audience?

Rather than asking vague questions, why not be pro-active and just give an answer.

Something like (and this is spitballing at 11:00pm on a Friday night so you know what the quality will be):

"Data is the lifeblood of businesses, yet you trust it to a glorified calculator. JIG re-imagines the spreadsheet, exposing data in new ways, ensuring you don't miss a thing."

Or: "30% of sales opportunities are lost because of incorrectly understood data, Jig exposes the trends for you so you'll never miss a deal."

Or: "Spreadsheets are complicated, they're messy and they're hard. Jig makes complicated spreadsheets quick and easy, giving you more time to focus on your business."

Or: "Excel buries data, JIG exposes it."

Or: "Excel was created in 1987, it was built for an simpler, less data-rich, era. JIG re-imagines the spreadsheet, with a focus on 2021 levels of data."

You get the picture.

Frame the problem, sell the solution, and instead of talking about the technology say how the technology helps.

Also, perhaps without customer testimonials find some case studies of times when excel has failed and what that failure cost. One that comes to mind, which is almost certainly too sensitive, is the contact tracing system in the UK that was built on excel. It failed when they ran out of rows causing hundreds of thousands of people to not be contacted about covid exposures. There will be tons of examples that aren't as life threatening that you can use to illustrate the benefits of Jig.

Yeah, but that's where the hustle and salesman instinct of a founder comes in. You've got to include it in a way that feels natural.

The fact that you've got a comment on the front page of hacker news about your products lack of awareness, yet you don't say what the product is or link to it explains a lot.

You need to hustle more. This is a huge opportunity to get it in front of hundreds of people.

Edit: I had to search through the page to find a link to your app. You need to make it more obvious.

Oh crap, I had no idea he'd died - I met him once when he was on his happiness tour, really interesting, genuinely nice, and driven guy. He took the idea of selling shoes and somehow morphed it into spreading happiness including touring it to markets that Zapos didn't operate in (like NZ where I met him), which obviously had limited direct benefit to his company. Only really visionary people would be able to pull off something like that and connect those dots.

I also met someone who grew up with him, he said that Tony was always looking at everything with an entrepreneurial eye. Anything and everything would be a business, even bringing in a grill to sell burgers to his class mates at lunch.

Big loss of a visionary.