Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (54)

On the role of Distinguished Engineer and CTO Mindset Apr 27, 2025 Software Engineering is here to stay Mar 3, 2024 Some thoughts on recent RTO announcements Jun 22, 2023 Some thoughts on the latest LastPass fiasco Mar 5, 2023 Working from home works as well as any distributed team Nov 25, 2022 If we stop feeding the monster, the monster will die Nov 20, 2022 Why I am a poll worker since 2020 Nov 11, 2022 Using GNU Make with JavaScript and Node.js to build AWS Lambda functions Sep 4, 2022 Scripting languages are tools for tying APIs together, not building complex systems Jun 8, 2022 Automation and coding tools for pet projects on the Apple hardware May 28, 2022 Am I getting old or is it really ok now to trash your employer on social media? May 25, 2022 Peloton could monetize these ideas if they only listen May 15, 2022 Most terrifying professional artifact May 14, 2022 Good idea fairy strikes when you least expect it May 2, 2022 A year of COVID taught us all how to work remotely Feb 10, 2021 Should we abolish Section 230 ? Feb 1, 2021 This year I endorse Joe Biden for President Aug 26, 2020 Making the best of remote work - Coronavirus blues Mar 16, 2020 The passwords are no longer a necessity. Let’s find a good alternative. Mar 2, 2020 All emails are free -- except they are not Feb 9, 2019 Returning security back to the user Feb 2, 2019 Which AWS messaging and queuing service to use? Jan 25, 2019 Using Markov Chain Generator to create Donald Trump's state of union speech Jan 20, 2019 Adobe Creative Cloud is an example of iPad replacing a laptop Jan 3, 2019 A conservative version of Facebook? Aug 30, 2018 Fixing the Information Marketplace Aug 26, 2018 On Facebook and Twitter censorship Aug 20, 2018 What does a Chief Software Architect do? Jun 23, 2018 Facebook is the new Microsoft Apr 14, 2018 Quick guide to Internet privacy for families Apr 7, 2018 Leaving Facebook and Twitter: here are the alternatives Mar 25, 2018 When politics and technology intersect Mar 24, 2018 The technology publishing industry needs to transform in order to survive Jun 30, 2017 Architecting API ecosystems: my interview with Anthony Brovchenko of R. Culturi Jun 5, 2017 Don't trust your cloud service until you've read the terms Sep 27, 2016 I am addicted to Medium, and I am tempted to move my entire blog to it Sep 9, 2016 Amazon Alexa is eating the retailers alive Jun 22, 2016 In search for the mythical neutrality among top-tier public cloud providers Jun 18, 2016 In Support Of Gary Johnson Jun 13, 2016 LinkedIn needs a reset Feb 13, 2016 In memory of Ed Yourdon Jan 23, 2016 We Live in a Mobile Device Notification Hell Aug 22, 2015 Ten Questions to Consider Before Choosing Cassandra Aug 8, 2015 On Maintaining Personal Brand as a Software Engineer Aug 2, 2015 Social Media Detox Jul 11, 2015 Book Review: "Shop Class As Soulcraft" By Matthew B. Crawford Jul 5, 2015 We Need a Cloud Version of Cassandra May 7, 2015 Ordered Sets and Logs in Cassandra vs SQL Apr 8, 2015 Microsoft and Apple Have Everything to Lose if Chromebooks Succeed Mar 31, 2015 On apprenticeship Feb 13, 2015 Configuring Master-Slave Replication With PostgreSQL Jan 31, 2015 Cassandra: Lessons Learned Jun 6, 2014 Thoughts on Wall Street Technology Aug 11, 2012 Scripting News: After X years programming Jun 5, 2012

Thoughts on Wall Street Technology

August 11, 2012

Last week I went on vacation and missed the news that a software error at a major market maker caused almost half a billion dollar worth of trading errors, which required a rescue by a group of investors. Mainstream media is quick to point out that high frequency trading should be more regulated, but as a software engineer I find that this has more to do with process and management than with the trading technology or software itself.

As I've been gathering my thoughts on this topic for the past few days I came across an article by Robert Dewar, one of my most respected professors at NYU Courant Institute where I did my masters. Dr. Dewar's main point is that safe and trustworthy software is possible if the company has proper processes and a proper culture in place.

Wall St. companies could learn from this. Companies so dependent on technology should not be run by traders -- they should be run by technologists. From CEO level down to the humblest engineers, these companies must be staffed with technically minded people who have the right training, the right attitude, and the right thought processes to build reliable and trust worthy software (but such developers are never on the market, so this creates a conundrum, right?)

How many Wall Street job openings have you seen that proclaim "fast pace" as one of the exciting aspects of the job ? To be clear, when a recruiter contacts me about such a job opening I immediately brush it off. It is this "fast pace" of development, this requirement that something requested this morning must be in production by midnight today, is what time and time again gets Wall St. technology into a pickle. As one of the commenter's on Dewar's article said, senior management and sales should not under any circumstances be allowed to rush software development process. Human mind is simply not capable of accelerating its cognitive processes, and therefore forcing developers to build software faster is counterproductive.

Following this line of reasoning that developers are humanly unable to think faster than they do, production support and active development must be thought of as two distinct areas that should be staffed by different people. Under no circumstances should engineers be forced into a situation where they are expected to deliver working code -- while also responding to phone calls from traders and customers every fifteen minutes. Bug fixes are too a distinct activity from software development.

Dr. Dewar concludes his article:
High-frequency automated trading is not avionics flight control, but the aviation industry has demonstrated that safe, reliable real-time software is possible, practical, and necessary. It requires appropriate development technology and processes as well as a culture that thinks in terms of safety (or reliability) first. That is the real lesson to be learned from last week's incident. It doesn't come for free, but it certainly costs less than $440M.

NASA's overall budget is about $10 billion per year. Wall Street technology spending is about $40 billion, depending on who you talk to. NASA is able to find developers and subcontractors who can program a robot from 250 million miles apart, or safely launch humans into orbit. Wall Street could benefit from recruiting the same kind of engineers and managers and offering them meaningful career paths.