Hacker News new | ask | show | jobs
by justboxing 2601 days ago
> The engineers frequently work from 9am-9pm and then some weekends. Is this common practice in the industry?

Yes, quite common. I've been a software engineer in the Investment bank industry for about 15 years, worked at various hedge funds, brokerages and asset management firms in Boston, NY and recently in San Francisco.

Just 1 out of 6 firms I worked at had any kind of test driven development. In my experience, the lack of testing is not from a "hustle" mentality. It has more to do with the fact that the Fintech space in general, and investment banking in particular always lags behind in technology and processes. In companies that I tried to incorporate some sort of unit tests and TDD, the push back always was "We don't have time in the project timeline for writing tests. There is a QA team that will do that." Either the benefits of tests in software development process hasn't been "sold" to the IT Managers, or they are completely unaware of it, coming from a traditional waterfall methodology.

Another thing that's been the driven of this workflow is that traders and portfolio manager routine so some sort of un-scalable automation for their workflow. I once worked with a Bonds trader who had an enormous spreadsheet with over 80 tabs, links to bloomberg realtime pricing, a bunch of macros and such. The work that my team used to get was to take that spreadsheet and turn it into a database driven application that wouldn't "Freeze" or "choke" periodically as it used to in Excel.

In such situations, which is also very common and you'll likely run into it, your manager will ask you to work with said trader or portfolio manager and do the conversion. In these type of projects also I wasn't allocated any time to write tests. As soon as a portion of the application is ready, the traders or PMs would themselves run tests against a QA instance. In order to keep my sanity, I would write tests that wouldn't be in source control and wouldn't tell my manager about it.

3 comments

If there are no parameters on what needs to be shipped at all costs, ship some output from /dev/random and go home.

If you need to ship some functionality in particular, you need a way to check whether what you've written is that functionality.

If you're only releasing once, then maybe a manual/interactive session with the artifact is good enough. But if you're making and releasing frequent changes, then automating the process saves time.

> "We don't have time in the project timeline for writing tests. There is a QA team that will do that."

What they are really saying is, "Currently if a bug makes it to production I can shift blame onto QA for missing it during testing, but if we start writing tests now I have to completely own it."

If you're starting with TDD and unit tests, then you're doing it wrong.

You have to start with integration tests, then go down the stack if you have time and resources.

> If you're starting with TDD and unit tests, then you're doing it wrong

Source?

Please. This is just plain wrong. Integration tests also belong to TDD.

Unit tests are very focused, individual, component level tests. Suppose, I want to test my mortgage calculator logic, without bothering about caching, data storage, network IO etc. Then, unit tests are the way to go. But, if I want to test the functionality, just like an end user then Integration Tests are the way to go.

You might also use Integration tests to get your stories approved.

One might say Integration tests belong to BDD. I'll say that is just a lower level categorization. At the top, it's just TDD.

In a world of no tests, a handful of high level tests on "critical path" functionality can make a huge difference. They can also demonstrate visible wins to unconvinced stakeholders.

I don't know the OP's world, but I can vouch for starting with high level tests being a good strategy in some cases.

Generally, I agree with this statement, but my experience shows me that there's a very important exception here: if a code implements any kind of parser or compiler, unit tests are a must for that part.
In the compiler I'm working on at work the integration tests have been the most useful.
I personally agree with this approach - but it's in vogue in my experience. I liked https://kentcdodds.com/blog/write-tests