|
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!).
|
|
|
|
|
maze3 wrote: But can technical debt be observed before hand?
Yes. Not to be flippant, but it's like how a car you are buying drops in value the minute you drive it off the dealer's lot. In my opinion, technical debt starts the minute the first line of code is written. It is immediately obsolete because the future will bring a new way of doing things. An example is how Microsoft removed the need to wrap Main in a namespace.
I suppose that's not a good example because the definition, from wikipedia:
Quote: In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
is more about your code than the changes in tooling/frameworks. I think the question is, is the quick fix a "simple" change because of a requirements change, or does the the quick fix inform you of a larger structural problem in the code base? Somewhere there's a balance. A one-off fix can later be refactored into a structural change if there is more evidence that a structural change is needed. That my 2c and how I've approached code changes in the past.
[longish story]
As a concrete example, a lot of what I do is write "parcel updaters." This involves taking data in other DB's or CSV files, correlating a record there to the appropriate parcel, and updating the parcel information. Originally, this work was done by others as SQL statements with no logging of errors, like "parcel not found" or of the changes being made. Lots of bugs, no way to figure out what the issue was. I started implementing new parcel updaters in C# with a lot of pre-checks to verify data integrity. It was all C#, and often slow because everything was loaded into memory. At some point, we started dealing with really huge and complicated datasets and I ended up writing SQL queries for things like "missing parcels" and many more complicated queries for parcel contacts, etc. This was really fast, and the insert/updates were still done in C#, but the C# code is now informed by SQL queries that anyone can run to see what parcel updater thinks it should be doing.
Now, am I going to go back and rewrite the existing C# parcel updaters to use this clearly improved process of dumping the CSV or other source into a DB table and writing the queries? No, but it is an example of how, after many use cases where these parcel updaters needed to be written, I've improved the process over the last two years, and frankly, yes, wish I had figured out then what I know now.
[end longish story]
|
|
|
|
|
If you look at the books on software engineering, the thing is that once you reach a level of code and have tested enough with test driven programming and the new devops.. and not to forget documentation and the new buzz words like continuous improvements over the air etc... your product will always be indebted to the people keeping it running.... no more gold master disks and iso's
But can technical debt be observed before hand ?
You have metrics for that in software development ? and you as a program manager need to keep track of such things if so... (google ...How to Reduce Technical Debt in Your Software Development Project?
its usual when a new person comes into a existing project..first think he would like to do is runway..just like the rest of us...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Indeed - possibly the most famous work, the mythical man month, basically says you should plan on throwing one away, but also warns of the second system effect, where you cram in all the things you had to leave out of the first.
|
|
|
|
|
Technical "debt" implies something that has to be paid back. If something is hard to maintain, say so. Doesn't mean it has to be fixed or rewritten. A user can also relate better to an outstanding "bug" report than "technical debt" ("Is he going to fix things or what?")
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
