4 ms·

That rewrite sounds like a great project to pair with junior developers on. It has all of the optimal features: 1) You pretty much have to TDD, but it isn't h

by tyre 11y ago

That rewrite sounds like a great project to pair with junior developers on. It has all of the optimal features: 1) You pretty much have to TDD, but it isn't hard to because you can start by writing tests that the old software passes as your "spec". 2) It actually matters if it works. As a junior dev, one of the hardest parts about giving a shit was that the tasks I was given often didn't matter. The quality of my code when I was younger scaled exponentially with the challenge and meaningfulness. As is true with many immature youths, I only acted like it mattered when it mattered. 3) A senior engineer would likely enjoy refactoring/rewriting something like this. Focus on getting it right, take time to craft elegant solutions, etc. Plus you get to teach someone 4) Large company with resources and domain to take a long-term outlook on the problem. UBS isn't going anywhere (I hope), so they are incentivized to take longer to write a solution that lasts another few decades. They can also take the time to train a junior developer without worrying that they'll miss their metrics for the next funding round. Honestly it sounds like a blast. Sign me up!

hitekker 11y ago
All excellent points; I don't disagree with anything except for the last one. > Large company with resources and domain to take a long-term outlook on the problem. My father works for company X that sold this system to banks; UBS and the other big ones didn't have a hand in the development other than testing and specifications. Additionally, company X and their clients suffer from enterprise-levels of political dysfunction and mismanagement, e.g., "let's fire our internal QA team and replace them with underpaid contractors from <insert third world country>. what could go wrong?", "the new system being developed by our new college hire employees in <another insert third world country> is 10 times slower than the old one? Well we'll just run it on 10 times more expensive hardware!" I could go on and on about the general shortsightedness, perhaps in a blog post[1]. Suffice it is to say: probably not the best idea to get signed on at the moment :-) [1] The perhaps is saving me from commitment.
- ethbro 11y ago
  To elaborate a bit further, I feel like the best way of stating it is that in large organizations changing or allocating resources to anything (no matter how obvious) needs a sponsor in the form of a person. That sponsor typically signs on because they really believe thing needs to get done and/or expect that if thing succeeds then they will look good. Rewriting working code is a hard project to find a sponsor for, unless you're lucky to have software engineers high up in the hierarchy with clout.
ams6110 11y ago
I assume the original system is Business BASIC or something like it. I used that in one of my first dev jobs in the 1990s at an investment bank. All their internal systems were written in Business BASIC. They had moved off of the original vendor's hardware and were running it on PA-RISC HPUX servers. Anyway -- the problem with developing tests for the old software is that there is no unit testing framework. You'd have to develop that too and unless you really invested in it you would not have stats like code coverage. Mocking out parts of the system would likely also be difficult because the code in such systems is normally spaghetti and not well abstracted. If you're lucky they have some standard test data that can be used to run through system tests -- but that's at a much higher level than TDD would ideally want. And I know the shop I worked at had nothing like that back in the day. Everything was tested by hand.
- kpil 11y ago
  Vms basic, most likely. Main problem is not the lack of frameworks, it's a whole different culture of how to test... Unfortunately, for the banks, they've not managed to maintain their withering infrastructure for a lot of reasons, and are just now realizing the threath from 'Fintechs' that are run by people that actually understands software development.

by tyre 11y ago

hitekker 11y ago

All excellent points; I don't disagree with anything except for the last one. > Large company with resources and domain to take a long-term outlook on the problem. My father works for company X that sold this system to banks; UBS and the other big ones didn't have a hand in the development other than testing and specifications. Additionally, company X and their clients suffer from enterprise-levels of political dysfunction and mismanagement, e.g., "let's fire our internal QA team and replace them with underpaid contractors from <insert third world country>. what could go wrong?", "the new system being developed by our new college hire employees in <another insert third world country> is 10 times slower than the old one? Well we'll just run it on 10 times more expensive hardware!" I could go on and on about the general shortsightedness, perhaps in a blog post[1]. Suffice it is to say: probably not the best idea to get signed on at the moment :-) [1] The perhaps is saving me from commitment.

ethbro 11y ago
To elaborate a bit further, I feel like the best way of stating it is that in large organizations changing or allocating resources to anything (no matter how obvious) needs a sponsor in the form of a person. That sponsor typically signs on because they really believe thing needs to get done and/or expect that if thing succeeds then they will look good. Rewriting working code is a hard project to find a sponsor for, unless you're lucky to have software engineers high up in the hierarchy with clout.

ams6110 11y ago

I assume the original system is Business BASIC or something like it. I used that in one of my first dev jobs in the 1990s at an investment bank. All their internal systems were written in Business BASIC. They had moved off of the original vendor's hardware and were running it on PA-RISC HPUX servers. Anyway -- the problem with developing tests for the old software is that there is no unit testing framework. You'd have to develop that too and unless you really invested in it you would not have stats like code coverage. Mocking out parts of the system would likely also be difficult because the code in such systems is normally spaghetti and not well abstracted. If you're lucky they have some standard test data that can be used to run through system tests -- but that's at a much higher level than TDD would ideally want. And I know the shop I worked at had nothing like that back in the day. Everything was tested by hand.

kpil 11y ago
Vms basic, most likely. Main problem is not the lack of frameworks, it's a whole different culture of how to test... Unfortunately, for the banks, they've not managed to maintain their withering infrastructure for a lot of reasons, and are just now realizing the threath from 'Fintechs' that are run by people that actually understands software development.