4 ms·

God, I want to short my codebase so hard. What would the engineering equivalent of that be, I wonder? Quitting and getting hired back as a consultant?

nostromo 12y ago
Just sell a company and codebase you've yet to create. If the market value seems greater before you've actually shipped: congrats, you just made money shorting your own company.
mbesto 12y ago
> God, I want to short my codebase so hard. Invest in your competitor.
- bryanh 12y ago
  If quality of code had a causal relation with success - that might be accurate. I'm not sure it does.
  - the_cat_kittles 12y ago
    i was going to write that good code is a necessary but not sufficient condition. but thats not true either!
    - deleted 12y ago
      [deleted]
    - chii 12y ago
      success of the business and good quality code does have a relation ship - it's just not an obvious one. Like reversing a car with a trailer, the direction you want to go can be difficult to control, but it doesn't mean your driving doesn't affect it.
curiously 12y ago
borrow money and hire an expert contractor and fire them and claim the credit and reap the rewards.
einhverfr 12y ago
Well, with LedgerSMB (http://www.ledgersmb.org http://www.ledgersmb.org), we forked from an absolutely horrid codebase. The author has been described by Matt Trout as "The guy Matt's Scripting Archive would have fired for bad coding." I mean the codebase was a total mess. Total, total, total mess. After 6 years of refactoring we now have a framework in place to start on the financial logic. It shouldn't take us more than 6 years to get the rest rewritten. One of the hidden costs of bad code is that it is contagious. After staring at bad code, it is very hard to write very good code. So it takes several revisions to go from bad code to good code, to get the patterns right, etc.
- crdoconnor 12y ago
  >One of the hidden costs of bad code is that it is contagious. That's why the debt analogy fits so well - because technical debt compounds. If your codebase is already heavily in technical debt, when developing new features or fixing bugs you are faced with three equally unpalatable options: 1) Do it properly (takes: 1 month) 2) Don't make it worse; don't make it better (takes: 1 week) 3) Just do a quick hack to work around all of the other hacks (takes: 30 minutes) As a developer with a pushy boss who doesn't understand technical debt and a tight deadline, the rational choice is pretty obvious: take 3, go home at a reasonable hour to your family, still meet the deadline and drown your professional sorrows in alcohol.
  - einhverfr 12y ago
    But that isn't taking into effect the contagion issue. In theory your view is the way it works. In practice doing it "properly" comes out half-properly because you spent all your other time maintaining horrible code so that it infects your thought processes and design. The problem is this. Let me put it clearly: If you are maintaining bad code, it will take you several tries to come up with a good architecture to replace it. You will make better progress having someone entirely outside do the architecture themselves. OTOH, if employers are going to use credit scores to decide whether to hire you, then technical debt may be an even better metaphor if you factor that in ;-)
- judk 12y ago
ChrisAntaki 12y ago
Be honest with your managers.
- artmageddon 12y ago
  That doesn't always get what you want, though. I've been working on a terrible project and even my managers know how bad it is, yet despite all their efforts to explain this to senior executives(need more people to work on it, more time to refactor, etc.), they simply don't want to hear it.

nostromo 12y ago

Just sell a company and codebase you've yet to create. If the market value seems greater before you've actually shipped: congrats, you just made money shorting your own company.

mbesto 12y ago

> God, I want to short my codebase so hard. Invest in your competitor.

bryanh 12y ago
If quality of code had a causal relation with success - that might be accurate. I'm not sure it does.
- the_cat_kittles 12y ago
  i was going to write that good code is a necessary but not sufficient condition. but thats not true either!
  - deleted 12y ago
    [deleted]
  - chii 12y ago
    success of the business and good quality code does have a relation ship - it's just not an obvious one. Like reversing a car with a trailer, the direction you want to go can be difficult to control, but it doesn't mean your driving doesn't affect it.

curiously 12y ago

borrow money and hire an expert contractor and fire them and claim the credit and reap the rewards.

einhverfr 12y ago

Well, with LedgerSMB (http://www.ledgersmb.org http://www.ledgersmb.org), we forked from an absolutely horrid codebase. The author has been described by Matt Trout as "The guy Matt's Scripting Archive would have fired for bad coding." I mean the codebase was a total mess. Total, total, total mess. After 6 years of refactoring we now have a framework in place to start on the financial logic. It shouldn't take us more than 6 years to get the rest rewritten. One of the hidden costs of bad code is that it is contagious. After staring at bad code, it is very hard to write very good code. So it takes several revisions to go from bad code to good code, to get the patterns right, etc.

crdoconnor 12y ago
>One of the hidden costs of bad code is that it is contagious. That's why the debt analogy fits so well - because technical debt compounds. If your codebase is already heavily in technical debt, when developing new features or fixing bugs you are faced with three equally unpalatable options: 1) Do it properly (takes: 1 month) 2) Don't make it worse; don't make it better (takes: 1 week) 3) Just do a quick hack to work around all of the other hacks (takes: 30 minutes) As a developer with a pushy boss who doesn't understand technical debt and a tight deadline, the rational choice is pretty obvious: take 3, go home at a reasonable hour to your family, still meet the deadline and drown your professional sorrows in alcohol.
- einhverfr 12y ago
  But that isn't taking into effect the contagion issue. In theory your view is the way it works. In practice doing it "properly" comes out half-properly because you spent all your other time maintaining horrible code so that it infects your thought processes and design. The problem is this. Let me put it clearly: If you are maintaining bad code, it will take you several tries to come up with a good architecture to replace it. You will make better progress having someone entirely outside do the architecture themselves. OTOH, if employers are going to use credit scores to decide whether to hire you, then technical debt may be an even better metaphor if you factor that in ;-)
judk 12y ago

ChrisAntaki 12y ago

Be honest with your managers.

artmageddon 12y ago
That doesn't always get what you want, though. I've been working on a terrible project and even my managers know how bad it is, yet despite all their efforts to explain this to senior executives(need more people to work on it, more time to refactor, etc.), they simply don't want to hear it.