Tech Debt - MPJ's Musings - Fun Fun Function
Вставка
- Опубліковано 20 сер 2024
- 💖 Support the show by becoming a Patreon
/ funfunfunction
Tech debt works kind of like debt in real life. You can accept tech debt to get what you want quickly*, but in return you’ll have to do *more work later*. Also similar to real debt, tech debt will *snowball if you keep adding on more and not paying it off.
🔗 mpj on Twitter
/ mpjme
🔗 The camera I use
amzn.to/2kwlpAD
🔗 The microphone and sound recorder I use
amzn.to/2kwli8e
amzn.to/2lcVSfd
🔗 The lights I use
amzn.to/2ld8jrX
I find the analogy of cleaning the room more close to the idea of tech debt. If you are late to work or came home tired it might be fine to throw your clothes on the floor and leave the shoes in the middle of the room and even leave the dishes on the table after you ate. But if you continue doing that without cleaning later on, not only it will be hard to find stuff in the apartment, others won't enjoy visiting you (or your code). The time it will take to get ready and leave next time(deliver the feature) will be much longer. Sometimes you will also move stuff and accidentally break something that was leaning on it that you didn't even see, like a plate on some shirt on your bed. Also if you don't regularly clean it will snowball very quickly.
+Slava Shpitalny oh shit that is MUCH better. It illustrates the problem much better and is so much more relatable.
...heh also messy houses tend to have more bugs too. Lots of places to hide and nest.
And the worst codebases are like what you see on the Hoarders TV show.
@@funfunfunction I still like your example too, I could picture the changes of purpuses of the room(s) and also the growing mess (cables, extensions, quick fixes that actually cause more chaos than solutions etc.). :D I enjoyed your viedo!!!
One thing to point out, is that tech debt is something SOMEONE will have to pay.
There are a lot of devs, and/or shops, who only build the first iteration. They are tasked with having to push out an mvp for a site or app. Then they move on to the next. Usually they will never work with that client again. This is often where the incentive is to push. It is dangerous.
Here, knowing you will unlikely have to deal with this project again, it's very easy to build a debt riddled project.
Not only is this wrong as you are failing your client, but it is also ingraining these bad habits in you as a developer/shop. There will be a day where you have to do some follow-on work and you will cry. Or, there will be a day where you have to build something larger and you will struggle.
Thanks MPJ for another awesome video and some great points!
I click your ads every time, this is the first time ever I have done that. I look forward to my commute on Mondays so I can watch your new video, I even think about it the night before and when I get up. It's always very insightful and funny, something I want to share with friends and colleagues. I don't mind that you aren't coding much right now, because you don't talk just because you can, you talk because you have something meaningful to say. At least that's how I feel when watching. Thanks Mpj, super glad to see that you are doing well and thank you for sharing the knowledge so that we can become better and happier developers and human beings!
+Erik Hellman thank you SO much for this
Dude. AMAZING VIDEO!
Cannot count the amount of times I saw a non-technical project manager frown when I said "Tomorrow I won't work on any features....I need time to clean up, improve design, organize the code base..."
As master Crockford says: GOOD SOFTWARE TAKES TIME!
(not necessarily long...but it takes an amount of time that cannot be reduced by ever increasing the tech debt!)
Leadership is a HUGE a problem imho.... you were SPOT ON!
Actually your comparison to the electric system in the old house was pretty good 👍
Are you Jesus?
Jesus didn't surf the water, he walked on water!
is that a yes or a no
Totally agree
@@toyflish Are you sure he was walking on water?
I had a meeting about Tech Deck the other day, impressed the higher ups with a sick finger flip.
I have been dealing with tech debt all my life in pretty much the majority of my projects. But I only learned of this concept by watching your videos. Thank you for it!
I miss being in college when the only thing that mattered is if my program worked and did what it was supposed to do. I turn my assignment in, it would be graded, and then no one would ever use it again. Now I actually have to write clean code.
I think your analogies is very good. Especially with the references back to financial debt, it really helps paint the picture accurately.
When I was starting to work in a team project, I was so frustated with my colleagues code quality, DRY violations, pep-8 violations (it's highlighted by their IDEs!) inconsistencies naming urghhhhh and I was the one that will be refactor all of them.... That's for me, my first tech debt.
It's good to learn the non-coding side of things in a developer's life and situations,before I even make an official debut in that field.Preparation is always healthy-that's why I'm subscribed to you
Most important is to explain necessity and importance about tech debts works. Managers just don't competent enough to decide such problems.
And log working time for insights, not making debts at home in free time.
Here's a common counter argument: "Shipping is money". Here's another: "If its work that we have to do at some point, then lets not do it until it we have to work on the feature again next year." Etc Etc Etc.
Your example of a post launch argument of "We need to fix it. It will save us time later" does not work with leaders that does not have some technical background (as you say in the video), or people who have become under pressure from management. Also in consulting you are expected to deliver working software and not something you have to fix later.
In my experience it has been easier to sell such an argument BEFORE you actually ship, but DONT EVER use words like "it will save us later" or "this is prettier code" etc !
Tell the people in charge that you do not have a stable version, and need that extra week NOW that you otherwise would have asked for later. Sometimes shipping is more important that tech debt though or you end up agreeing on shipping now and fixing later anyway (or not at all). BUT - and this is the point:
When you raise the issue upfront it works better with non technical people.
When projects/features ship - they are effectively signed off. The "budget" is closed. Asking for more "budget" when you are expected to work on another feature (and "budget") rarely works.
This has been my experience across several organisations.
The point I am trying to push through here is this:
Inform the leadership up front and finish your plate before moving on to the next course in the menu. Nobody likes cold leftovers anyway. (Analogy warning)
MPJ's example in the video where the team talks about refactoring AFTER the release is not something I would "recommend" if leadership is not informed upfront like this example:
"We have a problem we can hack around for a quick release. However to finish it completely we need time to analyse the problem/apply fix/refactor the code". Then hopefully the argument is not centered around if it should be done but when you are given time to clear your debt - before or after release.
In my experience it usually comes down to 2 things:
1) Timing, dont hide problems talk about what you do
2) Wording, non tech people dont appreciate the "it will be better afterwards" argument family. This is especially true if if they already have a working shipped feature, and item 1) was not applied.
I hope this clarifies my original reply for you.
PS. this only focusses on times where you - due to time constraints - had to hack around an issue or something like that. If you just write plain bad code and does not clean up its up to you to improve :-)
Morten Fischer I don't work in the industry yet, so I'm wondering how scheduling releases actually works. It seems like across the world things are always trying to be pushed out so fast that cuts are made to meet deadlines. How common is it for employers to demand deadlines that don't leave time to either do the job properly in the first place or make it stable/clean it up before or after launch?
In my experience, bad deadlines comes from bad project management. Very rarely from pushy clients or bosses. In my current job we work with an agile flow like scrum. One of the things scrum means is that no task should be too big to estimate without some degree of certainty. If there are questions unanswered at the time of estimating, you cant rely on the estimate etc. So if you base your deadline on sketchy estimates then you heading for trouble and sleepless nights.
Btw, pushy clients or bosses are usually those without a tech background or understanding and they can be handled like I propose: Be upfront and clear. Say things like they are. Cut the buzz and bulls...t.
If everything else fails: Move to a job ;-) No paycheck is worth that kind of frustration.
I found the video and this comment very useful, thanks!
I would say I have experienced immovable deadlines and the technical debt is not resolved either way. I have also worked at places where it has been cleared however, _but_ these were in-house teams instead of agencies.
Its more likely that the project requirements were changed after the hard deadline was set which caused the problems.
So true, tech debt can be crippling and I spend at least 50% of my time justifying the time to sort it out.
Very energetic, I like your teaching style, I used the same old house analogy in re-engineering class
Keep it up!
Microsoft has so much tech debt.
Great video. This is especially useful where the team I'm in keep wanting to add features without going back and repaying the debt.
I've been going through the same thing handling a code base for a project which was built long ago. Can really relate with this.
Your explanation is superb... thank you so much for making this video. I've been searching everywhere to understand this subject. May Allah reward you.
For my opinion, good example is when you develop combat-ready prototype (aka MVP) and you just don't know how things will go for some feature - you usually do it in a simpler way, mark down into task manager a note about it and it let people to approbate and give you a feedback.
"We shall not ship shit." Uncle Bob.
In my experience, I found that when the leader is not a developer, you will not be able to pay technical debt. The problem is that there is no way to quantify the quality of the code and show how much that debt will cost later. It usually is a matter of trust. It is meaningless to argue with people who do not have expertise without data to prouve that you have tech debt. It's like telling that you really should start to cut cost and pay back now without knowing how much you earn and how much you owe. I would think that tracking bugs generated per commits/task done per day/static analysis and adding those data in the decision making process is the first step to win the battle.
Nordic accents are great, your "yust" (just) puts a smile on my face every time :P
in Mexico i think the problem is no matter if you only have 4 weeks for the development, the client always chance requiements and always the dev team is guilty. we are in red numbers with tech debt
Great video, as always! Hope the ambiance of your videos don't change much once you move! ( Don't forget the plants :P )
This one really deserved a like. Congratulations !
Let's send this to the PM: "Whatch this video, start at 8'14''. The messages we receive (or give) in this situation are almost the same "not budget any more now", "we need to work on this other feature now", ...
Nice video, and the analogy is OK! You swedish programmers are lucky. Don't ask why, cause I am a Moroccan.
Wow congrats on 70 000 subs! You're awesome!
+TOKYOYO Japan-Johanna aww
Another great episode! Thanks. You should be moving constantly if that is the key to these great episodes. :D
This analogy is so f'in accurate!
A version sequence 1.0, 2.0, 3.0, 4.0 ... has higher technical debt than,
1.0, 1.1, 1.11, 2.01, 2.1 ...
Also one would think a good version control team culture would help "manage".
Refactoring pays down "debt"?
I guess my experience was much the same as yours, I only truly became aware of it when I was swimming in it.
Excellent video, and overall great channel, mpj. A few non-techie team leads I know could do with watching this vid in particular. Many thanks.
managing technical debt should really be in the culture of modern development teams. developers should be allowed and encouraged to keep it low. so it's tech leaders' (CTO) responsibility to deal with it.
this video hit home so hard.
well said sir!
It gets even worse when multiple developers have been working with the codebase over many years.
@funfunfunction. after this great argument for managing debt. I would like to see some code alongs of you cleaning up spaghetti code ( especially on a project that to you didn't write original . open source? ) which at times is more complex than starting from. scratch.
congrats on getting the apartment. Be sure to think through its setup for your videos so you don't have to fix things later.
epic explanation
This is so relatable haha
5:38 - For a second, I thought that was a copy of "Physical graffiti" by Led Zeppelin.
Tech debt is bad, but the negative interests are worse! Can you do a video about bitcoin and cryptocurrencies from your point of view?
like always educational and fun :)
Has MPJ every stated what camera he uses? Looks great!
+aflashyrhetoric Its in the description
+aflashyrhetoric the Camera is only part of it though, check the behind the scenes episode
...Can't believe I missed that - sorry. Thank you and thanks for the great videos, MPJ!
Tech debt is a fairly poor analogy tbh. Code complexity is typically a network effect, so the difficulty of cleaning it up is an exponential function (both in volume and in time elapsed). Additionally to the "debt" metaphor one might consider it to have a time dependent interest rate if the original author fixes tech debt in a small amount of time (say < 3 months), but if a different person has to do it or much later then it becomes very difficult to even know how to change something.
I wonder, does use of some specific theck, that seems a good idea at the time and turns out not to bee a good idea in the future is also considered a tech debt. Or does it become an instant tech debt once you realize that it wasn't such a good idea.
Nice Shirt
I have an interview with a recruitment agency on Wednesday for a general web dev position. Does anyone know what can I expect?
How do you manage to keep the leaves from falling of from your IKEA-tree? I have tried several, and they have never survived.
have you tried to apply water on it?
Oh yes. I think the first times I gave it too little water, so this time it seems to go better. Still, it seems to need more sunlight than I am able to provide for it, so I hope that will not be a show stopper.
Tech Debt = Spaguetti Code
Great video, bro. It may sound a little random, but which camera did you use to film it? Many thanks!!
+btsxxx see the behind the scenes episode
when are you moving in your new home ?
Iast wanted to say thank you for the video. It's iast precisely correct. Can you make a video about iest testing framework from Facebook? Like, iast about iest. :troll:
Hi MPJ love your videos, but I have question that is not about programing.
What camera are you using for making your videos, and when you are filming outdores what are you using for camera stabilizer.
+jacky jones check the Behind the scenes episode, links to my current gear in the description