I *heart* Technical Debt(baberuth.posterous.com)
baberuth.posterous.com
I *heart* Technical Debt
http://baberuth.posterous.com/i-heart-technical-debt
3 comments
Chill out guys.
There's a balance between deliberately writing garbage and trying to start with perfection, and you choose some middle ground.
Yes, write maintainable code. No, don't accrue technical debt just for the fun of it. The post is titled as if all other things equal I would prefer paths that result in more technical debt, but that's clearly moronic.
But you have to start with step 1 (or I guess you can start with step 2...). The point for me is that I end up a lot more long term productive if I get my ass in gear on "get it done" first, because it helps me get to "test" and "refactor" a lot sooner.
That doesn't have to be true for everyone, but it seems to be true for me... this week anyways.
There's a balance between deliberately writing garbage and trying to start with perfection, and you choose some middle ground.
Yes, write maintainable code. No, don't accrue technical debt just for the fun of it. The post is titled as if all other things equal I would prefer paths that result in more technical debt, but that's clearly moronic.
But you have to start with step 1 (or I guess you can start with step 2...). The point for me is that I end up a lot more long term productive if I get my ass in gear on "get it done" first, because it helps me get to "test" and "refactor" a lot sooner.
That doesn't have to be true for everyone, but it seems to be true for me... this week anyways.
2nd half of Step 3 reminded me of Kent Beck's exhortation:
1) Make it run.
2) Make it right.
3) Make it fast.
1) Make it run.
2) Make it right.
3) Make it fast.
And often step 1 is a valuable learning experience, as well, both long-term and also for the immediate needs of the project at hand.
But, sadly for the OP, the very name "debt" clearly indicates there is no escaping step 3.
But, sadly for the OP, the very name "debt" clearly indicates there is no escaping step 3.
Actually, no I don't think it does indicate that. He's saying that he loves technical debt because it means things get written fast and furious, and he can just leave the technical debt to someone else. If he hated the debt, he'd take care of it.
The number of times I got hired to pick up after you because your technical debt technically bankrupted the company and you got fired. My only hope is that innocent new coders reading your piece will not feel "inspired" by your little bracelet waving, but instead learn how to get good at her craft. That's the real reason it takes you 5 days of "procrastination". What you need is not to "just get it done", is to learn and gain experience before you tackle something out of your league, so that you don't leave other people picking up the pieces. Please.
The point of Technical Debt isn't procrastinating about perfection - the point is when you get into a situation where you've dug yourself in so far that you end up screwed.
For example, I consider the entirety of the Virtualization industry to be primarily caused by technical debt surrounding legacy Windows programs. Simpler to convert an old physical server into a VM than to redo the application.
The fact that you actually have the code and can change the codebase = you're far from incurring any insurmountable technical debt.
For example, I consider the entirety of the Virtualization industry to be primarily caused by technical debt surrounding legacy Windows programs. Simpler to convert an old physical server into a VM than to redo the application.
The fact that you actually have the code and can change the codebase = you're far from incurring any insurmountable technical debt.
Yes, a startup needs a 'get it DONE' attitude, but that HAS to be tempered with doing things in a maintainable way, and not just duct-taping it together. If you don't, you're forcing a complete rewrite of the entire system, and that is a really dangerous thing to do.
So let's give some better advice for startup programmers:
1) Get it done. Just hack out that code and make it work.
2) Write some tests for the poor thing. If you -can't-, you'll need to do step 3 first and then come back.
3) Refactor/Rewrite that horrid, horrid code you wrote in step 1. Make it readable, first of all. Then make it intelligible. Then make it pretty.
If you work at that company in the future, you'll thank yourself. If you don't, the owners and your predecessors will thank you.
And best of all: Writing good code is a habit. Once you get into the habit, it will horrify you if you ever have to stop, even temporarily.