I love simple things, thank you for sharing!
Simple Systems Have Less Downtime
11–20 of 271 posts
Re: Simple Systems Have Less Downtime
#12I love simplifying things.
I'm not sure I follow, could you break that down for me?
Re: Simple Systems Have Less Downtime
#13His website had this annoying message about subscribing for updates that has no obvious way of getting rid of it excepting by clicking the accept button. I guess that's simpler than having an additional "no thanks" button.
The article was a formulaic retelling of well known wisdom too.
Re: Simple Systems Have Less Downtime
#14>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart. I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems wit…
That's true for drag&drop tools that provide a user interface as an alternative but Looker or similar tools introduce their own language that limits your capability by sandboxing the environment but still lets you programmatically define your models. See LookML for Looker ( https://docs.looker.com/data-modeling/learning-lookml/what-i... ) or Jsonnet for Rakam. ( https://docs.rakam.io/docs/compose ) P.S: I'm affiliate…
I think that’s missing the point he was making. No matter what front-end representation of a system you get, the implementation backing a no-code system will have edge cases around interactions both internally and with third-party systems. The fact that you’re hiding a system behind a veneer of “no code” doesn’t hide the fact that code is behind the actions that are taking place, it just means you can’t introspect it (even if this “no code” is in fact code).
I think a better point would be to make that that’s not a bad thing, sometimes abstractions provided in “no code” systems can greatly simplify a solution. But even the most well-designed solution will fail to some essential complexity of the root-problem the original authors didn’t understand. Without debugging tools (or privileged access to the backend of the implementing system) it’s difficult or impossible to understand what went wrong.
Re: Simple Systems Have Less Downtime
#15Every new programming style epiphany is an ad hoc, intuitively-specified, hazy restatement of the Unix Way.
If Unix is your yardstick for simplicity, that just shows how far we've come…
Re: Simple Systems Have Less Downtime
#16Using the company this author helped to migrate to hubspot as an example.
I'm not sure if the simpler solution - hubspot existed when the company started hacking solutions together.
Also, the move to hobspot was relatively easy because the business processes and workflows were already well known and defined.
Starting from scratch, fighting the fires as they appear, a bit of patchwork seems unavoidable.
Everything is obvious in hindsight.
I guess the real lesson here:
Simplify once in a while. Like Facebook just did with messenger.
Re: Simple Systems Have Less Downtime
#17I don’t know, most systems like the container ship he/she described just seem simple but are actually pretty intricate inside. The logic behind them might be easy to understand, but the devil is in the details. A combustion engine is also simple conceptually: make stuff explode in a closed chamber to move a rod, convert that the movement to a rotation of a shaft. Super simple, yet I doubt I could debug many problems my car engine has with such basic knowledge.
Re: Simple Systems Have Less Downtime
#18Do they also have less people using it?
Re: Simple Systems Have Less Downtime
#19It's important to find a compromise. The simplest system at my work would be something like a php/mysql backend hosted on a old fashion shared server using ftp.
Good luck attracting good developers with that. We use something over engineered but we have fun. The customers don't care but we do.
Re: Simple Systems Have Less Downtime
#20>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart. I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems wit…
As somebody who built a lot of Looker, it is not no-code for this very reason. It's why your Looker data model is stored in hand-editable code and under version control!