2,349 karma · joined February 27, 2013
The way I look at it, there will always be a delta between the code you have and the business features you want/need. Independently of whether the code was written 30 years ago or yesterday.
So the only question worth asking IMHO is how best to reduce the delta while maximising the business value/cost ratio.
If you talk about “tech debt” without talking business value/cost then you are indulging in “what would be fun to do” and not “what is the best next step for the business”.
The biggest lie by the way is “it will improve maintenance!”. Maybe for you (because you spent years rewriting it and know it inside out) but not for the unlucky next person who has to take over your code.
Another lie is using words like “Modern!” and “Brand New!” as if it is a good thing. I want the old software that has proven itself for more than 30 years. Not the “Modern! New! Shiny!” crap that has been implemented by bright eyed inexperienced beginners, is full of bugs, implemented using a “Modern!” framework that will stop being maintained in a year, and has 5% of the features of the “old” software.
The cruelty of managers never stops surprising me. As long as she is doing her job and is presentable etc. what’s the problem? Worst case just ask her to park her car somewhere else?
The 10x developers I have worked with are all excellent communicators. The worst developers I have worked with most definitely weren’t.
The least efficient/productive company I have ever worked for had formal meetings all the time. What takes a week where I work now would take 6 months there.
So no I don’t agree that meetings are automatically productive/useful in general. I am pretty sure you can measure how productive a software company is by the following formula:
Time spent working on projects divided by Time spent in meetings.
I found that commment to be seriously rude and disrespectful. Yes I should have avoided the "100% nonsense" comment. However that doesn't give you licence to be rude and abusive in return.
A prioritised to-do list.
It’s simple. It works.
So it is kinda obvious to me that non-developers also will benefit from fast feedback loop software.
I have worked on systems with the same functionality but architectured as a single monolith + database. Maintaining that system was a walk in the park comparatively.
Examples:
Declarative: I want a PC with the following code installed: X, Y and Z. Imperative: First upgrade X, then install Y, then uninstall W, then install Y and Z.
The company I work for is still using old Fortran code to simulate how long it takes for trains with a certain load to get from A to B given a sequence of gradients. I bet small bits of Fortran still lives inside many systems written in C/C++.
Having said that, I would never recommend C as the language of choice for new projects.
Which frankly amazes me. The game was released in 1998!