|
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.
|
|
|
|
|
In my role we used to take on technical debt before the fact. We work with Java webservices and the majority of our infrastructure used to be Apache Tomcat / Spring / JSP-based deployments. As we started taking on greenfield projects we were pushing to move to newer technologies like Spring Boot, Thymeleaf, even Angular/React. Unfortunately because our team's experience was mostly in the "older" tech, we spent a while developing new applications using that stack.
It was only when a few us put our foot down and said "enough is enough" did we manage to start developing software using the new technologies which has, admittedly, made life entirely easier (deploying a containerized Spring Boot application vs. maintaining and deploying to a Tomcat instance on some random server somewhere).
Unfortunately the damage is done though for the earlier applications, and since we still have to develop and maintain those we're finding the development estimates for those to be much higher than our more recent applications. That's a technical debt we knew was coming, and now we have to live with.
(And I'm sure a few years down the line the technology we think is cutting-edge will become redundant and we'll be the old farts still clinging onto it bringing in technical debt for future generations!)
|
|
|
|
|
Yes, there is no such thing as "our technical debt", it is always "their technical debt".
|
|
|
|
|
Consider the following scenario: a customer has orders of type A and B and they should be handled (slightly) differently.
You think to yourself, I'm going to apply a strategy pattern with a factory and gracefully handle every edge-case without if-else logic and without the risk of changes to A will affect B and vice versa and where adding C is a breeze and you wouldn't even need to compile or re-deploy the application.
Instead, due to time constraints, you write a simple if-else.
And the code works and nothing changes in the logic for the lifetime of the application and you never see the code again.
Is it technical debt?
Now say you were able to implement your first idea and you're really happy about it, but then they say A has to change, but B too, and we'll add C and D all the way through Z and they change weekly and your code, while it works and follows best practices, becomes unwieldly and impossible for anyone else to understand.
Is it technical debt?
Now let's say you have and if-else branch and C, D all the way through Z are added, but adding another if-branch is easy as pie (though not necessarily best-practice).
Sure, you need to deploy a new version of the software every time, but that's easy as you use best DevOps practices.
Basically, a request for change could be written in a day and most developers would have no trouble adding an if-branch.
Is it technical debt?
I think technical debt is defined by how the code is used, how often it changes (and how easy it is to change), and by the team supporting it.
Sometimes you just know it'll be a problem, sometimes you don't.
Sometimes you'll expect something to be a problem, but it won't (and vice versa).
It's the same as weeds in your garden, it's only weed if you don't want it there (otherwise it's known as a plant, insects love them!).
|
|
|
|
|