• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that ...I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• Didn't we document this services?
• I thought we'd tested this module...
• Fixing this will break that... I think
• Don't touch that, last time someone touched $whatever broke
• Write a comment and we'll fix it later
• Write a TODO so it'll be fixed later
• Write a comment there, just above the TODO
• I just changed ONE line!

• "Ward" Cunningham is an American computer programmer who developed the first wiki.
• You start writing an application. In the beginning there is no need for user roles. Everyone can do anything. At some point you start having two different permissions for a specific action. The tech team considers whether to create a full fledged permission system, but at this point it really looks like over engineering. Some time later another thing requires the differentiation of users, and then another and another. The solution is refactoring it to have a decent permission system. To make this refactoring will take way more time than just adding another method, but will simplify the code and make future permissions to be added with one line of code, or even by just adding a row in the database.
  • * 4 now (the permission), 22 later (the refactoring, that now is a bit more complicated)
  • * 21 now (the refactoring), 0 later (the permission)
  • * 4 now (the permission), no refactoring at all, and then 5 for the next permissions, and then 6, 7… until the point a new refactoring is suggested, now costing 50-something

1. Interest - Every minute you spend with not very clean code
2. Capital Pay off - Refactoring
3. Extending a loan - Design negligencies
4. Bankruptcy - Situation with an interest over the debt so large that it is impossible to move forward and we need a complete rewrite
5. Technical Inflation - When the current level of our technology is old enough to lose compatibility with the rest of the industry
6. Fiscal Amnesty - Discard prototypes, products or components and renounce to use them

• Intended: “No time to do it multi-language, that will be done in the future”
• Intended: “No time to complete the tests, that will be done when we deploy this in PRO”
• Not intended: Letting someone to write code that does not follow a certain standard
• Not intended: An important design decission that ultimately fails
• Not intended: Left the junior programmer unsupervised
• Design: non optimal solutions, shortcuts
• Tests: Not many automatic tests and too many regression testing
• Documentation: Only a few properly know the system
• Hardware, environments,... too many manual actions

1. Whenever we can, we measure productivity (Scrum)
2. We spend too much time in regression testing
3. It is increasingly difficult to meet the deadlines
4. Leads to anomalies and support problems
5. Lack of quality and control
6. The teams suffers too much pressure
7. 80% of of the time is spent reading code, if not understood can not be built
8. It's all so delicate that there is no way to touch without breaking anything
9. We are not able to update versions

• The mantra created by LinkedIn’s founder Reid Hoffman “if you are not embarrassed by the first version of your product, you’ve launched too late” quickly became an excuse for an anything goes approach. Thousands of startups have launched and failed precisely for the lack of quality.
• MVP vs MLP

Exercise: Draw your technical curve (link)

• Real curve vs desired curve
• old debt is bad and new debt is good
• The real curve (chainshaw)
• Debt baseline and debt ceiling
• TDD and Scrum help

It’s a responsibility of the tech team to make business understand the consequences of this kind of action

• Technical debt can be paid by refactoring. It takes time but it’s doable. But when code is just bad, refactoring is way, way harder.
• Michael Feathers, have defined legacy code as code without tests:

  “Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”

When developers propose a big rewrite, and for whatever crazy reasons, business agrees, the stage is set for a new kind of failure:

• It turns out that it’s virtually impossible to track all functionality in a legacy code base, and few rewrite projects take the huge necessary time to document everything.
• Business will ask is about deadlines. Estimating a big rewrite is probably one of the most unrealistic things one can try to do.
• Business will not accept all new features to be halted. Therefore there will be the need to keep track of them, and to reimplement them as well. And all relevant data should be migrated
• In the rush to convince business, developers will promise all kinds of things, like that the refactoring will make the system faster, more robust or scalable…
• Given part of the problem was developer’s inexperience in coding itself, how can they guarantee that now they know better?
• Generally, planning is not a particular strength of the kind of project that ends up needing a rewrite. Will the rewrite be properly planned?

Ron Jeffries thinks it is always BAD:

• Agile software development is about turning “next time” into “this time”, as often and as frequently as we can. It’s about improving the design as often as we can, as soon as we can.
• Sooner, or later, it seems, we’ll have an idea or an understanding that we can’t put in, because we, or the software, has moved on. But if we can put off that moment as long as possible, we’ll do better