|
#Worldle #263 2/6 (100%)
π©π©π©π¨β¬βοΈ
π©π©π©π©π©π
https://worldle.teuteuf.fr
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
These apps with JavaScript Backends are the future...if you can't fight them join them....
Caveat Emptor.
"Progress doesn't come from early risers β progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
abmv wrote: JavaScript Backends are the future...if you can't fight them join them....
I just registered and am an Official Card-Carrying Member!! OCCM's Unite!!!
|
|
|
|
|
Olivia makes all the customer data easily viewable by all users and makes it easy for customers to view what other customers are buying and for how much.
Olivia puts the app "in the cloud".
|
|
|
|
|
And that is the interesting thing.
This doesn't mention the MAJOR POINTS:
1. Where does the data come from? - A DBA did a lot of work
2. How does Olivia know how to connect to that data? - A developer holds the hand to get it working & is blamed when it doesn't.
3. What is her security level that she can read / write data? Who set all of that up?
Honestly, the data is the difficult thing. Yeah, probably if you have the data stored properly anything is easy.
There's just a lot of missing parts in that Dog & Pony show video.
And, it's kind of irresponsible because managers all over the Universe are yelling at people, "It's very easy because I saw the 2 minute 15 second video!!!" 
modified 11-Oct-22 16:23pm.
|
|
|
|
|
And then she can analyze it with Power BI - one of the most developer intensive BI solutions around. Oh and Power BI hooks you into the entire MS server eco system.
And it is every managers wet dream!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
And, and, and ...
... The customer bought EVERYTHING!
|
|
|
|
|
|
Oh, well, I see the neighbours are buying som adult toys 
|
|
|
|
|
We just took the course: "marketing hype 101".
I'm in!
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
P.S.
βThatβs one sure tip-off to the fact that youβre being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality. And people buy it! The business press goes wild!β -- Donβt Let Architecture Astronauts Scare You β Joel on Software[^]
|
|
|
|
|
I have joined their webinar once. I have tried all their tutorials. The marketing videos and the ads lied. Microsoft's Power Apps suck. I would rather use old trustworthy WPF and Entity Framework if someone ordered a native Windows app from me.
Also there's no way a non IT manager can make her own proper program with Power Apps. Yeah.. she will leak all consumers' data to each other.
|
|
|
|
|
Very interesting. Thanks for sharing your experience.
That is exactly what I thought from watching the video too. It's just 100% hype.
|
|
|
|
|
I can't get my head around how one can avoid technical debt, because I think now it only something created after the fact.
consider making a new product: I, ME, wants to make version B of the product, because it will be better, meaning less "technical debt" (being bugs, and code short cuts, which will need refactoring to make for performance or means to expand features in future)
but I need to make version A to get to version B.
Sure with experience, version A might be closer to B, but this "inferior" version will still exist. With unlimited resources we could make version A a prototype, but practically A allows for generating some revenue to cover the starting costs.
Now from an outside viewer, they have the benefit of observation and can point out some technical debts that will be incurred.
but that outside viewer can also be your self, after making version A, and taking a step back to observe and go ah, yeah, this would be better if changed.
You go buy something with credit, you can see what the debt will be BEFORE accepting.
But can technical debt be observed before hand? Not include the, well well go with Option 1 now, and transition to 2 next year. You have already created what Option 1 is, thus in the stage of observing.
not sure what the point is, kind just felt like when someone new comes into a team, and first thing they start mentioning is technical debt this and that, and like, yeah, no sh*t, its easy to critique after the fact, how the projects you made before coming here looking.
|
|
|
|
|
|
Greg Utas wrote: I wrote an article that touches on a lot of what you said: The Software Rewrite[^].
I can highly recommend that article. Particularly the advice to refer to a proposed re-write as "re-engineering" to avoid scaring people.
|
|
|
|
|
I don't know what is worst...
- Thecnical debt
or
- hystorically grown (in Germany "Historisch gewachsen")
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
What's the sense of Historisch gewachsen? That something has always been done that way, so there's great resistance to changing it, even if it's dysfunctional?
|
|
|
|
|
Yes and no
It was started in a way, it is mostly functional but without logic, structure and clarity, and everytime there is an addition, one has to pay more attention to find the things that need to be "used" and to not break something existant than actually doing it the right way.
It is feels kind of similar to Stack Overflow Patchwork | CommitStrip[^] but forced by the existant software itself and without copying the chunks it from the internet.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Technical debt is the term applied to deferring a proper fix that will take lots of time and resources, instead performing a technically inferior fix that can be done quickly and cheaply. It is most often incurred during bug fixes / maintenance, not during design of the original product. It is sometimes required when a product version must be out ASAP, (e.g. when a client is expecting a fix) and is always put in with the intention of fixing the bug properly "later".
In some cases, a "quick and dirty" product will be produced with the intention of revising it in a later version. This usually happens when the product must be demonstrated by a particular date (e.g. for a show, upper management, etc.). Often this "quick and dirty" solution will then be released to customers.
From the engineering perspective, all forms of technical debt are bad. From that cash flow perspective, having some income from an inferior (but working) product is better than having no income from a better product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Releasing an inferior product to your most important launch customers is a recipe for product failure. When managers ask engineers to cobble something together, they generally imagine that you will produce perfect, customer pleasing code faster than you otherwise would because they asked you using whatever words make the engineers acquiesce. It's a form of magical thinking.
Now you have bad code in the field that must be supported first, before engineering can produce a properly working solution, and your launch customers are dissatisfied with your bodged-together prototype. Customers will ask for the important features you left out, so engineering will be under pressure to rush those features into production, resulting in an inferior product that is bigger and harder to maintain that must be supported before you can produce a properly working solution. This is technical debt.
|
|
|
|
|
Technical debt is always a bad idea from the Engineering point of view, and usually from the Management point of view as well.
The only case where it might be justified (again, by Management, not by Engineering) is when money is running out, and having something to put on the market is seen as better than having nothing. The gamble here is that the time (and money) bought by the inferior version might allow the company to release the better version.
Note that Combat Damage Control on a Naval ship works in a similar manner - get things working NOW, and do a proper fix when there is time. The Captain would definitely not want to sideline the ship in mid-battle to make proper repairs; by the time they are finished, the battle may be lost.
The problem is that this reasoning is used for less-defensible cases, such as releasing a product in time for a show, or releasing it in time for it to affect the annual bonuses of those in charge of the product.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The goal of combat damage control in naval warfare is to preserve the ship until it can be refit. The problem with comparing incurring technical debt to damage control is that in business, the battle never ends; there is no down time during which to reduce any accumulated technical debt.
Startups may think they're being smart by allowing technical debt to accumulate, but IMHO this is an illusion. What happens is that they can remain in business for a few extra months, but their software development effort cannot scale due to the technical debt. They simply flame out later, having eaten through additional investor cash. As an investor I would be wary of any CEO who chose to accumulate technical debt.
|
|
|
|
|
Finally, I understand what that is. I kinda imagined it as something clever that was done and becomes too complicated for future generations to expand on.
But what you described is a hack, a kludge...that usually lacks any elegance and so one day has to be refined.
(sigh) Yeah, many videogames have their storied hacks, but if it's a one time, it doesn't matter, otherwise the next use of the 'engine' will replace the hack or kludge...hopefully.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
