3 ms·
Not a CTO and I've never come close to having a conversation with one. As a developer, though, I've been burned by tech debt too many times to feel comfortable
by pjbster 8y ago
Not a CTO and I've never come close to having a conversation with one. As a developer, though, I've been burned by tech debt too many times to feel comfortable with it.
The biggest problem with technical debt is that everyone has a different tolerance for it. Some even have an appetite for it. This is a breeding ground for conflict.
The next biggest problem is that the people who take it on are rarely the same people who end up paying it off. The former tend to get showered with kudos whilst the latter experience stress and poor performance reviews.
IMO the worst kind of technical debt is that which is taken on to route around a business process ("Governance"). So it, sort of, contributes to faster delivery but the conditions which drive the choice tend to persist until a regime change so the compromise sticks around forever.
In an ideal world, you should only agree to take on technical debt if you are also presented with a repayment plan. And that leads to my final problem with technical debt: most people tend to assume that that last part will take care of itself.
- pavel_lishin 8y ago> IMO the worst kind of technical debt is that which is taken on to route around a business process ("Governance"). So it, sort of, contributes to faster delivery but the conditions which drive the choice tend to persist until a regime change so the compromise sticks around forever. Can you give an example?
- pjbster 8y agoClient access to database: too much effort to get stakeholder sign off for api changes and regression testing so we'll just grant the client full access to the database schema. Now we can't change the schema without breaking zero, one or many clients. DBA deployment processes: insist on taking system offline for cold backup. Every. Single. Time. Solution: make application run dynamic code which is stored in a database table. Effect releases by issuing UPDATE statements. It's hard to argue that an Oracle database can't handle one of these reliably so the DBAs don't require cold backups for these. Still, we no longer have compiler support so our tests had better be solid. Bonus con: the DBAs cottoned on and started doing the cold backup thing for these updates so we lost business agility too. Finally: a legacy web service. No toolchain but we do have WSDL and source. Ported to Weblogic in 30 minutes. Fits in with current infrastructure, more performant and gives company an opportunity to decommission the old box. But PM hasn't got a Jira for this work and we're already into integration testing so throws it out. The architect resigns. Governance. A.k.a. Insurance-Against-Corporate-Liability. Responsible for at least 3 fucked up systems during my tenure there.